Package lock files like package-lock.json or yarn.lock are causing merge conflicts that feel impossible to resolve. These conflicts happen when different team members install packages or update dependencies on separate branches, creating a tangled mess of version numbers and checksums.
Step-by-Step Fixes
Step 1: Accept the incoming changes (fastest fix)
The quickest solution is often accepting all incoming changes from the branch you’re merging. This works best when you trust the other developer’s dependency updates.
“`bash
git checkout –theirs package-lock.json
npm install
git add package-lock.json
git commit
“`
This approach is ideal for when you haven’t made any critical dependency changes yourself. It’s the fastest path to resolution but not recommended when you’ve carefully updated specific package versions for security or compatibility reasons.
Step 2: Keep your current version
If your local changes are more important, preserve your package lock file instead.
“`bash
git checkout –ours package-lock.json
npm install
git add package-lock.json
git commit
“`
This method works best when you’ve recently audited dependencies or fixed security vulnerabilities. Use this approach when your branch contains critical updates that shouldn’t be overwritten.
Step 3: Delete and regenerate (most reliable)
When the conflict looks too complex, starting fresh often saves time. Delete the lock file and let npm or yarn rebuild it.
“`bash
git rm package-lock.json
git commit -m “Remove conflicted package-lock.json”
npm install
git add package-lock.json
git commit -m “Regenerate package-lock.json”
“`
This technique is ideal for situations where both branches have legitimate changes. It ensures all dependencies work together properly by letting your package manager figure out the correct versions.
Step 4: Manual resolution for specific packages
Sometimes you need surgical precision. Open the conflicted file in VS Code or your preferred editor to see the conflict markers.
Look for patterns like:
“`
<<<<<<< HEAD
“version”: “2.1.0”
=======
“version”: “2.2.0”
>>>>>>> feature-branch
“`
Choose the version you need, remove the conflict markers, then run npm install to verify everything works. This approach is best used when only a few packages are causing issues and you need specific versions.
Step 5: Use npm’s built-in resolution
As of npm 7 and newer versions in 2025, there’s a smarter way to handle these conflicts.
“`bash
npm install –package-lock-only
git add package-lock.json
git commit
“`
This command tells npm to update only the lock file based on your package.json requirements. It’s particularly useful when the conflict stems from different installation orders rather than actual version disagreements.
Likely Causes
Cause #1: Different npm or yarn versions
Team members using different package manager versions create slightly different lock file formats. npm 6 generates different structures than npm 8 or 9, leading to massive conflicts even when installing identical packages.
Check your npm version with:
“`bash
npm –version
“`
Fix this by standardizing your team’s npm version. Add an .nvmrc file to your project specifying the Node.js version, which includes a specific npm version. Have everyone run nvm use before installing packages.
Cause #2: Installing packages in different orders
When developers install packages at different times or in different sequences, the dependency resolution can vary. Developer A might install react then redux, while Developer B installs redux then react, creating different lock file structures.
Prevent this by always running npm install without arguments after pulling changes. This ensures everyone’s lock file reflects the same installation order based on package.json.
Cause #3: Mixing package managers
The worst conflicts happen when some team members use npm while others use yarn or pnpm. Each manager creates different lock files with incompatible formats.
Check for multiple lock files:
“`bash
ls -la | grep -E “(package-lock|yarn.lock|pnpm-lock)”
“`
Choose one package manager for your entire team. Add the unused lock files to .gitignore and document the choice in your README.md file.
When to Call an Expert Help
Consider getting senior developer help when you see cascading failures after resolving conflicts. If npm install produces errors about peer dependencies or version mismatches after trying these fixes, you might have deeper compatibility issues.
Call for backup immediately if the conflicts involve security-critical packages like authentication libraries or encryption modules. These aren’t worth risking with quick fixes.
Teams experiencing daily lock file conflicts need architectural help. This pattern suggests workflow problems that technical fixes won’t solve alone. A senior developer can implement better branching strategies or automated dependency updates.
Copy-Paste Prompt for AI Help
Here’s a prompt to get specific help with your package lock conflict:
“I have a Git merge conflict in my package-lock.json file. My npm version is [YOUR VERSION]. The conflict involves approximately [NUMBER] packages. The main packages in conflict are [LIST MAIN PACKAGES]. I’m merging from [BRANCH NAME] into [TARGET BRANCH]. My last successful npm install was [TIMEFRAME] ago. What’s the safest resolution strategy that preserves security updates while maintaining compatibility?”
Replace the bracketed sections with your specific details before pasting into ChatGPT, Claude, or Perplexity for customized guidance.