{
  "id": 11100861,
  "title": "How to fix package-lock.json merge conflicts (and yarn.lock, poetry.lock, go.sum) the right way",
  "url": "https://urgent.news/2026/10/01/how-to-fix-package-lock-json-merge-conflicts-and-yarn-lock-poetry",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-01T03:35:05.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/jaytank/how-to-fix-package-lockjson-merge-conflicts-and-yarnlock-poetrylock-gosum-the-right-way-3hpf"
  },
  "original_language": "en",
  "account": "When you rebase on the main branch and encounter a merge conflict in a lockfile, such as package-lock.json, the usual reflexes are misguided. Simply hand-editing the markers or accepting both changes results in an inaccurate dependency tree. While one side may appear correct, the other branch's new dependencies are missed from the lockfile. A lockfile is essentially the build output of the manifest, so resolving the manifest manually is necessary. Following this, give the tool a lockfile it can read and let it regenerate the lockfile. Both npm, Yarn, and pnpm can read a conflicted lockfile and merge both sides. For other tools like Cargo, one clean side of the lockfile is required first.\n\nThe table of lockfiles is as follows:\n- npm: `npm install --package-lock-only --ignore-scripts`\n- Yarn (v1): `yarn install --ignore-scripts`\n- Yarn (berry): `yarn install --mode=update-lockfile`\n- pnpm: `pnpm install --lockfile-only --ignore-scripts`\n- poetry: `poetry.lock --ours poetry lock` or `poetry lock --no-update` (for Poetry 1)\n- uv: `uv.lock --ours uv lock`\n- Cargo: `cargo update --workspace`\n- go: `go mod tidy`\n- composer: `composer update --lock --no-install --no-scripts`\n- Gemfile.lock: `bundle lock`\n- Pipfile.lock: `pipenv lock`\n\nDuring a rebase, `--ours` refers to the branch you rebase onto, not your branch. For Cargo, avoid `cargo generate-lockfile` as it performs upgrades, turning a merge into an upgrade. The `--ignore-scripts` flag is intentional, as you are regenerating a lockfile, not building, so there's no need to run install scripts from packages you haven't reviewed.\n\nVS Code has a free extension called LockSettle that automates this process. It flag conflicted lockfiles (including in monorepos), refuses to proceed if the manifest is still conflicted, displays the exact command in a confirmation dialog, runs it as a visible task in the right folder, and checks for leftover markers before staging the file. All commands are overridable, and the extension does not require network access or telemetry, ensuring safe operation within a workspace. You can find it on VS Code marketplace using `code --install-extension jaytankdev.locksettle`.",
  "summary": "You rebase on main and git stops: CONFLICT (content): Merge conflict in package-lock.json The usual reflexes are all wrong: Hand-editing the markers away gives you a dependency tree no resolver would produce. \"Accept Both Changes\" leaves duplicate JSON keys or invalid TOML/YAML. Accepting one side looks fine, but the other branch's new dependencies are silently missing from the lock. The rule A…",
  "key_points": [
    "Merge conflicts in lockfiles like package-lock.json must be resolved manually, not hand-edited",
    "Tools like npm, Yarn, pnpm can read conflicted lockfiles and merge both sides automatically",
    "VS Code LockSettle extension automates resolution of conflicted lockfiles in VS Code"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}