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.
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).
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-only
The
yarn [install]
will also actually do the install, which is slower and clobbers my nicenode_modules
made 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.