Deleting `package-lock.json` to Resolve Conflicts quickly

Question

In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.

Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?

Accent

Refer this answer - https://mcmap.net/q/56797/-what-is-the-role-of-the-package-lock-json – Directional

@john-mutuma Since npm has a much easier solution than the accepted answer maybe you should consider accepting that (my) solution below instead :-) Why waste time on something that can be fixed for you much easier? :-) – Wengert

Answer 1

Yes, it can and will affect all the project in really bad way.

1. if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"

2. even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.

Conclusion: don't ever delete package-lock.json.

Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.

In your case you better do next way:

1. fix conflicts in package.json
2. run npm install

As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.

Per docs npm will fix merge conflicts in package-lock.json for you.

[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.

Strake

With the Approach 2, I've noticed it easily leads to problems where I end up to the Approach 1 anyway, so I would recommend to go with Approach 1 in the first place. – Pad

@Pad why if it's basically the same thing? If you opt in the first to rebase on the current package-lock.json or accept "their" package-lock.json on the merge, they're actually the same. Or am I missing something here? – Crysta

if I use absolute versions, I mean without ^ or ~, is package-lock.json required? – Angle

@JRichardsz, you still don't explicitly control transitive(indirect, 2nd+ level) dependencies – Strake

The last line in this answer is the key. After pulling and seeing that the merge conflict is only in the package-lock.json file(s), you can just do an npm install and it will resolve them for you (then you just have to stage/commit/etc.). TIL :) Thanks for that tip! – Lelalelah

@Strake when should I run yarn install (Step 2)? Do I click "accept theirs" for example, in the merge dialog (using webstorm), and then run yarn install? – Enterpriser

@giorgi moniava just yarn, not yarn install. Rest is correct, but I'm wondering why you are going to use "accept theirs" instead of leaving both changes? Are you fine to lose changes you've made so far? – Strake

@Strake What I did now web storm has "Apply All Non-Conflicting Changes" for both branches in merge dialog. Then there was one conflicting line which I resolved myself. Then did yarn is that what you meant? – Enterpriser

@giorgimoniava yes – Strake

@Strake ok just one thing I don't get, above like I said I resolved the conflicts (inside yarn.lock): some using "Apply All Non-Conflicting Changes", one manually. Which conflicts did doing yarn afterwards resolve then? – Enterpriser

wait, no need to resolve conflicts inside of yarn.lock. only inside of package.json – Strake

@Strake yeah when I was shown merge dialog I thought I also had to take action for yarn.lock file, seems I had to "ignore" it... – Enterpriser

Answer 2

Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.

By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).

Anyway there is already a standard solution for it.

1. Fix the conflict inside package.json
2. Run: npm install --package-lock-only

Check out this link for more info:

https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts

Wengert

If "moduleX" needs to be 1.0.0 (not greater) then shouldn't 1.0.0 be specified in package.json instead of ^1.0.0 ? – Licketysplit

@Licketysplit if at the point of installing the module the latest is 1.0.0 how would you know that 1.0.99 will have breaking changes?? We can't predict the future. Also it might not have any breaking features or bugs - following semantic versioning just bugfixes, why would you opt out of them? In any case it should be a conscious descision when you update and not by misstake by following bad practices.. – Wengert

This does not work for meg. No conflicts in package.json, but I still have more than 2000 changes and a bunch of conflixts in package-lock. json no matter how many times I run npm install --package-lock-only. – Haggerty

@Hfrav Meg perhaps you are rolling a really old node (and npm) version, latest is V18. – Wengert

Nah. 14.16. The node version is controlled by the project, not me. – Haggerty

if --package-lock-only does not modify local node_modules tree, why we need to provide that option? – Oust

@ShashankBhatt Not sure, but I can imagine that it might be faster that it knows it doesn't need to install any modules but only resolve conflicts in the lock file and also for it to know it needs to do that which it might not try to do during the normal install – Wengert

okay but let;s say conflicts came for this scenario - someone added new npm package in node_modules (and package.json as well) for older npm/node combo and merged to main branch and then i was in other my own branch with newer npm/node combo and if i try npm install --package-lcok-only, will this install that new package to node_moduies which i don;'t have right now since when it is merged to main? – Oust

Answer 3

I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.

Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver

Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.

Edit: This repository is now archived and read only.

Fullblooded

Answer 4

I think if someone updates any dependency when working as a team, he needs just to notify others or mention it in the commit description. Then the lockfile can be ignored, so there will be no lockfile confilcts.

Muttonhead

Actually, if tests pass, then changing the dependency is perfectly legit: it does not create regression, the team has no reason to refuse it, especially if it is needed to code a new feature. – Rader

@EricMORAND: I read your detailed answer and i get your point, it makes sense. Thanks. – Muttonhead

this could have been a comment instead – Carricarriage

Answer 5

npm i --force does the work for me

Batruk

Answer 6

I have a different opinion: don't track package-lock.json at all.

The typical argument in favor of tracking it is this one taken from @skyboyer response:

Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.

This is a falacious argument. Stability is not guaranteed by package-lock.json. Stability is guaranteed by tests. If you cover your code with enough tests, a simple breaking change in the dependency graph that impacts your code will be detected at test-time.

Note two things:

• A breaking change in a dependency may totally not impact your product since you may not use the feature that was broken
• If a sub-dependency comes with a breaking change, your tests will detect it at then you can enforce the version of this sub-dependency in your package.json file.

Considering all the challenges and problems that tracking package-lock.json brings, having to enforce a sub-dependency once every many years is worth it:

• conflicts on a daily basis
• not benefiting from the latest security fixes
• long-term maintenance nightmare that makes migrating to a major version very difficult: by locking sub-dependencies, major incompatiblities are not detected immediately and add up to the point where moving from a major framework version to the next becomes a nightmare of dependency hell - Angular guys, doesn't it seem familiar?

In the course of the last 5 years, we had to enforce a sub-dependency version once (yes, only once) and we have been working on hundreds of different projects. So definitely, things are much more stable today than they were 5 years ago and not tracking package-lock.json is cheaper and easier than tracking it now.

Rader