To prevent from mismatch between package.json and package.lock (or between whatever-dependency-manager.json and .lock files) just don't edit them manually. Always use the package manager, whether it be for adding, upgrading or removing a dep.
And you could also add a check in your pre-commit hook to be sure that no one in the team will commit something wrong.
The issue that can arise with out-of-sync lockfiles isn't due to people editing them manually. To be honest, I don't think anyone does.
The problem is with changes people might do to package.json. They might not even edit that manually, but instead it would happen while developers will resolve a merge conflict, and unintentionally a change in the package manifest will slip in.
There's also the issue of pnpm vs yarn (and sometimes even npm, imagine that), because they create separate lockfiles.
So, whichever you used to edit package.json, you will still probably need to run npm install --package-lock-only and, if the default for the project is yarn, literally run a whole yarn. (Or is there a --lockfile-only equivalent for yarn?)
I'm not using version lens. Does that also care to update the package lock file when you do that? (as in, not update it "by hand" too, but actually re-ran the locking through the relevant package manager.
Also, I think you mean --package-lock-only? In yarn, just a yarn install will resolve conflicts.
The problem is not how the files get out of sync, but rather the fact that you'd not want to propagate this 'out of sync' behavior to your CIs or other devs (which is even worse as it will just drive more confusion).
Not so ideal when the package.json alone changes.
These are changes that aren't as soft as other things that you can force on the team by putting them on commit hooks.
I think we agree that regardless, your CI/build systems should work with the pure lock file and not try resolve.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To prevent from mismatch between package.json and package.lock (or between whatever-dependency-manager.json and .lock files) just don't edit them manually. Always use the package manager, whether it be for adding, upgrading or removing a dep.
And you could also add a check in your pre-commit hook to be sure that no one in the team will commit something wrong.
Hey Boris! Nice to e-meet you :)
The issue that can arise with out-of-sync lockfiles isn't due to people editing them manually. To be honest, I don't think anyone does.
The problem is with changes people might do to package.json. They might not even edit that manually, but instead it would happen while developers will resolve a merge conflict, and unintentionally a change in the package manifest will slip in.
Pre-commit hooks - I'm all up for those! :-)
I sometimes edit them "by hand" with Version Lens
There's also the issue of pnpm vs yarn (and sometimes even npm, imagine that), because they create separate lockfiles.
So, whichever you used to edit package.json, you will still probably need to run
npm install --package-lock-onlyand, if the default for the project isyarn, literally run a wholeyarn. (Or is there a--lockfile-onlyequivalent foryarn?)I'm not using version lens. Does that also care to update the package lock file when you do that? (as in, not update it "by hand" too, but actually re-ran the locking through the relevant package manager.
Also, I think you mean --package-lock-only? In yarn, just a
yarn installwill resolve conflicts.The problem is not how the files get out of sync, but rather the fact that you'd not want to propagate this 'out of sync' behavior to your CIs or other devs (which is even worse as it will just drive more confusion).
It does not. It totally should, but at the moment it does not. Literally just writes to the file for you.
Yeah,
npm i --package-lock-only && pnpm i --lockfile-onlyThe
yarn [install]will also actually do the install, which is slower and clobbers my nicenode_modulesmade bypnpm.Not so ideal when the package.json alone changes.
These are changes that aren't as soft as other things that you can force on the team by putting them on commit hooks.
I think we agree that regardless, your CI/build systems should work with the pure lock file and not try resolve.