I just recently upgraded to npm@5. I now have a package-lock.json file with everything from package.json. I would expect that, when I run npm install
that the dependency versions would be pulled from the lock file to determine what should be installed in my node_modules directory. What's strange is that it actually ends up modifying and rewriting my package-lock.json file.
For example, the lock file had typescript specified to be at version 2.1.6. Then, after the npm install
command, the version was changed to 2.4.1. That seems to defeat the whole purpose of a lock file.
What am I missing? How do I get npm to actually respect my lock file?
This question is related to
node.js
npm
npm-install
package-lock.json
You probably have something like:
"typescript":"~2.1.6"
in your package.json
which npm updates to the latest minor version, in your case being 2.4.1
Edit: Question from OP
But that doesn't explain why "npm install" would change the lock file. Isn't the lock file meant to create a reproducible build? If so, regardless of the semver value, it should still use the same 2.1.6 version.
Answer:
This is intended to lock down your full dependency tree. Let's say
typescript v2.4.1
requireswidget ~v1.0.0
. When you npm install it grabswidget v1.0.0
. Later on your fellow developer (or CI build) does an npm install and getstypescript v2.4.1
butwidget
has been updated towidget v1.0.1
. Now your node module are out of sync. This is whatpackage-lock.json
prevents.Or more generally:
As an example, consider
package A:
{ "name": "A", "version": "0.1.0", "dependencies": { "B": "<0.1.0" } }
package B:
{ "name": "B", "version": "0.0.1", "dependencies": { "C": "<0.1.0" } }
and package C:
{ "name": "C", "version": "0.0.1" }
If these are the only versions of A, B, and C available in the registry, then a normal npm install A will install:
[email protected] -- [email protected] -- [email protected]
However, if [email protected] is published, then a fresh npm install A will install:
[email protected] -- [email protected] -- [email protected] assuming the new version did not modify B's dependencies. Of course, the new version of B could include a new version of C and any number of new dependencies. If such changes are undesirable, the author of A could specify a dependency on [email protected]. However, if A's author and B's author are not the same person, there's no way for A's author to say that he or she does not want to pull in newly published versions of C when B hasn't changed at all.
OP Question 2: So let me see if I understand correctly. What you're saying is that the lock file specifies the versions of the secondary dependencies, but still relies on the fuzzy matching of package.json to determine the top-level dependencies. Is that accurate?
Answer: No. package-lock locks the entire package tree, including the root packages described in
package.json
. Iftypescript
is locked at2.4.1
in yourpackage-lock.json
, it should remain that way until it is changed. And lets say tomorrowtypescript
releases version2.4.2
. If I checkout your branch and runnpm install
, npm will respect the lockfile and install2.4.1
.
More on package-lock.json
:
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
This file is intended to be committed into source repositories, and serves various purposes:
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
To facilitate greater visibility of tree changes through readable source control diffs.
And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
In the future, you will be able to use a --from-lock-file
(or similar) flag to install only from the package-lock.json
without modifying it.
This will be useful for CI, etc. environments where reproducible builds are important.
See https://github.com/npm/npm/issues/18286 for tracking of the feature.
It appears this issue is fixed in npm v5.4.2
https://github.com/npm/npm/issues/17979
(Scroll down to the last comment in the thread)
Update
Actually fixed in 5.6.0. There was a cross platform bug in 5.4.2 that was causing the issue to still occur.
https://github.com/npm/npm/issues/18712
Update 2
See my answer here: https://stackoverflow.com/a/53680257/1611058
npm ci
is the command you should be using when installing existing projects now.
EDIT: the name "lock" is a tricky one, its NPM trying to catch up with Yarn. It isn't a locked file whatsoever. package.json
is a user-fixed file, that once "installed" will generate node_modules folder tree and that tree will then be written in package-lock.json
. So you see, its the other way around - dependency versions will be pulled from package.json
as always, and package-lock.json
should be called package-tree.json
(hope this made my answer clearer, after so many downvotes)
A simplistic answer: package.json
have your dependencies as usual, while package-lock.json
is "an exact, and more importantly reproducible node_modules tree" (taken from npm docs itself).
As for the tricky name, its NPM trying to catch up with Yarn.
Use the newly introduced
npm ci
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.
There is an open issue for this on their github page: https://github.com/npm/npm/issues/18712
This issue is most severe when developers are using different operating systems.
Short Answer:
npm install
honors package-lock.json only if it satisfies the requirements of package.json.npm ci
.Here is a scenario that might explain things (Verified with NPM 6.3.0)
You declare a dependency in package.json like:
"depA": "^1.0.0"
Then you do, npm install
which will generate a package-lock.json with:
"depA": "1.0.0"
Few days later, a newer minor version of "depA" is released, say "1.1.0", then the following holds true:
npm ci # respects only package-lock.json and installs 1.0.0
npm install # also, respects the package-lock version and keeps 1.0.0 installed
# (i.e. when package-lock.json exists, it overrules package.json)
Next, you manually update your package.json to:
"depA": "^1.1.0"
Then rerun:
npm ci # will try to honor package-lock which says 1.0.0
# but that does not satisfy package.json requirement of "^1.1.0"
# so it would throw an error
npm install # installs "1.1.0" (as required by the updated package.json)
# also rewrites package-lock.json version to "1.1.0"
# (i.e. when package.json is modified, it overrules the package-lock.json)
I've found that there will be a new version of npm 5.7.1 with the new command npm ci
, that will install from package-lock.json
only
The new npm ci command installs from your lock-file ONLY. If your package.json and your lock-file are out of sync then it will report an error.
It works by throwing away your node_modules and recreating it from scratch.
Beyond guaranteeing you that you'll only get what is in your lock-file it's also much faster (2x-10x!) than npm install when you don't start with a node_modules.
As you may take from the name, we expect it to be a big boon to continuous integration environments. We also expect that folks who do production deploys from git tags will see major gains.
Use the npm ci
command instead of npm install
.
"ci" stands for "continuous integration".
It will install the project dependencies based on the package-lock.json file instead of the lenient package.json file dependencies.
It will produce identical builds to your team mates and it is also much faster.
You can read more about it in this blog post: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable
Probably you should use something like this
npm ci
Instead of using npm install
if you don't want to change the version of your package.
According to the official documentation, both npm install
and npm ci
install the dependencies which are needed for the project.
The main difference is,
npm install
does install the packages takingpackge.json
as a reference. Where in the case ofnpm ci
, it does install the packages takingpackage-lock.json
as a reference, making sure every time the exact package is installed.
Source: Stackoverflow.com