I'm not sure this is completely correct any longer with the latest version of NPM?
From my understanding, npm install command will still use the main packages file, and updates the lock file. This is why people constantly see the lock file being updated in commits.
To use the exact versions as specified in lock file, you can use npm ci. This is intended for builds/deploys so you never get newer versions than what someone developed on.
So I created a project named 'project' and did npm install --save vue-extra@1.0.0 and cloned it three times so there's 'projectclone1', 'projectclone2' and 'projectclone3'
projectclone1
In projectclone1 I have same package.json and package-lock.json as the original project (which means I did not change anything manually) and I run npm install so it installed the same version as original that is v1.0.0 of vue-extra
projectclone2
In projectclone2 also I had the same package.json and package-lock.json but here instead of doing npm install I did npm install --save vue-extra which updated the package changing the package.json and package-lock.json so it installed the latest version that is v1.1.4 of vue-extra
projectclone3
In projectclone3 I opened package.json and manually changed vue-extra:"^1.0.0" to "^1.1.4" and did npm install, Here since I updated package.json npm considered package.json as a matter of truth and installed v1.1.4 of vue-extra and it also updated package-lock.json to v1.1.4
So if your package.json is somehow changed or updated and the version in package.json does not match with the version in package-lock.json then it will install the version from package.json and will update the package-lock.json accordingly.
Interesting, thanks for taking the time to run those tests!
Out of curiosity, what version of NPM are you using? I think some of the confusion is behavior changed at some point. So, depending on what version various team members are on, they see different actions.
I am using v6.11.2 and yes you are right the behavior had some issues and some changes during v5.x.x but now I guess almost all of them are fixed so v6 has been pretty stable about the behavior of package-lock.json
if you change package.json, package-lock.json will be updated
But if you do not change anything manually then it will ignore the ^ from package.json and will install the version that is mentioned in package-lock.json.
Thank you for reading and do correct me if I am wrong.
Hi Saurabh, my post was made on mobile so please excuse it's lack of detail. I've experienced package-lock.json updating itself in both development and CI environments and subsequently builds have failed when sub-dependencies have introduced bugs or breaking changes despite following semantic versioning. npm ci faithfully installs the correct package versions in the CI environment.
As to why this happens, I'm not sure. I agree that what you've said should work yet in practice I've seen it to not always be the case.
The npm team seem to acknowledge this, here's a quote from their blog:
npm ci promises the most benefit to large teams. Giving developers the ability to "sign off" on a package lock promotes more efficient collaboration across large teams, and the ability to install exactly what is in a lockfile has the potential to save tens if not hundreds of developer hours a month, freeing teams up to spend more time building and shipping amazing things.
Yeah even ive ran into problems where 100s of lines were updated in my package-lock.json so i think it is because a lot combinations are possible like i mentioned above plus if you've seen dependabot commits, they update package-lock to bumb versions but along with that they also change the integrity hash so it doesn't end up creating conflicts.
also a lot of time we pull from other branches so if any of them updated your dependent package they may end up updating the tree in package-lock
so yeah a lot of permutations and combinations to think about :(
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 sure this is completely correct any longer with the latest version of NPM?
From my understanding, npm install command will still use the main packages file, and updates the lock file. This is why people constantly see the lock file being updated in commits.
To use the exact versions as specified in lock file, you can use npm ci. This is intended for builds/deploys so you never get newer versions than what someone developed on.
I may be misunderstanding though...
So I created a project named 'project' and did
npm install --save vue-extra@1.0.0and cloned it three times so there's 'projectclone1', 'projectclone2' and 'projectclone3'projectclone1
In projectclone1 I have same package.json and package-lock.json as the original project (which means I did not change anything manually) and I run
npm installso it installed the same version as original that is v1.0.0 of vue-extraprojectclone2
In projectclone2 also I had the same package.json and package-lock.json but here instead of doing
npm installI didnpm install --save vue-extrawhich updated the package changing the package.json and package-lock.json so it installed the latest version that is v1.1.4 of vue-extraprojectclone3
In projectclone3 I opened package.json and manually changed vue-extra:"^1.0.0" to "^1.1.4" and did
npm install, Here since I updated package.json npm considered package.json as a matter of truth and installed v1.1.4 of vue-extra and it also updated package-lock.json to v1.1.4So if your package.json is somehow changed or updated and the version in package.json does not match with the version in package-lock.json then it will install the version from package.json and will update the package-lock.json accordingly.
I hope this clears up everything
Thanks for reading and asking this question.
Interesting, thanks for taking the time to run those tests!
Out of curiosity, what version of NPM are you using? I think some of the confusion is behavior changed at some point. So, depending on what version various team members are on, they see different actions.
See this S.O. post for an example of the confusion - stackoverflow.com/questions/450220...
I am using v6.11.2 and yes you are right the behavior had some issues and some changes during v5.x.x but now I guess almost all of them are fixed so v6 has been pretty stable about the behavior of package-lock.json
In the same stackoverflow answer I found this link of the issue github.com/npm/npm/issues/17979#is... which I found pretty useful.
This is how it works, author is incorrect.
Hi, You should checkout this reply : dev.to/saurabhdaware/comment/eoo4
and this comment from github: github.com/npm/npm/issues/17979#is...
So yes
^from package.json and will install the version that is mentioned in package-lock.json.Thank you for reading and do correct me if I am wrong.
Hi Saurabh, my post was made on mobile so please excuse it's lack of detail. I've experienced package-lock.json updating itself in both development and CI environments and subsequently builds have failed when sub-dependencies have introduced bugs or breaking changes despite following semantic versioning.
npm cifaithfully installs the correct package versions in the CI environment.As to why this happens, I'm not sure. I agree that what you've said should work yet in practice I've seen it to not always be the case.
The npm team seem to acknowledge this, here's a quote from their blog:
npm ci promises the most benefit to large teams. Giving developers the ability to "sign off" on a package lock promotes more efficient collaboration across large teams, and the ability to install exactly what is in a lockfile has the potential to save tens if not hundreds of developer hours a month, freeing teams up to spend more time building and shipping amazing things.blog.npmjs.org/post/171556855892/i...
It seems hundreds of developers on SO are also confused about npm's lock behaviour: stackoverflow.com/questions/450220....
Yeah even ive ran into problems where 100s of lines were updated in my package-lock.json so i think it is because a lot combinations are possible like i mentioned above plus if you've seen dependabot commits, they update package-lock to bumb versions but along with that they also change the integrity hash so it doesn't end up creating conflicts.
also a lot of time we pull from other branches so if any of them updated your dependent package they may end up updating the tree in package-lock
so yeah a lot of permutations and combinations to think about :(