3 ms·

That is incorrect. Both `npm install` and `npm ci` respect the lock file, and if a lock file is present, will make the `node_modules` tree match the lock file

That is incorrect. Both `npm install` and `npm ci` respect the lock file, and if a lock file is present, will make the `node_modules` tree match the lock file exactly. `npm ci` is optimized for a cold start, like on a CI server, where it's expected that `node_modules` will not be present. So, it doesn't bother looking in `node_modules` to see what's already installed. So, _in that cold start case_, it's faster, but if you have a mostly-full and up to date `node_modules` folder, then `npm install` may be faster, because it won't download things unnecessarily. Another difference is that `npm ci` also won't work _without_ a `package-lock.json` file, which means it doesn't even bother to look at your `package.json` dependencies.

gkop 8y ago
Thanks for the reply Isaac! This doesn’t match my first-hand experience unfortunately. Are there any circumstances under which npm install with a lockfile present deviates from the lockfile where npm ci does not? For example, why did this person experience the changing lockfile? https://github.com/npm/npm/issues/17101 https://github.com/npm/npm/issues/17101 Or why do these docs say? > Whenever you run npm install, npm generates or updates your package lock https://docs.npmjs.com/files/package-locks https://docs.npmjs.com/files/package-locks Oh, this seems like what I experienced: https://stackoverflow.com/a/45566871/283398 https://stackoverflow.com/a/45566871/283398 It does appear that npm works somewhat differently than the “obvious” way we would expect package managers to work vis a vis lockfiles :( At least npm ci gets the job done for my use case :)
- IsaacSchlueter 8y ago
  If you run `npm install` with an argument, then you're saying "get me this thing, and update the lock file", so it'll do that. `npm install` with no argument will only add new things if they're required by package.json, and not already satisfied, or if they don't match the package-lock.json. In the bug linked, they wanted to install a specific package (not matching what was in the lockfile), without updating the lockfile. That's what `--no-save` will do. The SO link is from almost 2 years ago, and a whole major version back. So I honestly don't know. Maybe a bug that was fixed? If this is still a problem for you on the latest release, maybe take it up on https://npm.community https://npm.community or a GitHub issue?
spdionis 8y ago
> Both `npm install` and `npm ci` respect the lock file This is not correct. `npm install` will update your dependencies, not install them, disregarding the package versions defined in the lock file. It feels like you are not getting the point of having a lock file in the first place. It should be obvious that you can't do an install (which npm calls ci) if you don't have a lock file. The lock file represents your actual dependencies. Package.json should only be used to explicitly update said dependencies.
- IsaacSchlueter 8y ago
  If you run `npm install` with no arguments, and you have a lockfile, it will make the node_modules folder match the lockfile. Try it. $ json dependencies.esm < package.json ^3.2.5 # package.json would allow any esm 3.x >=3.2.5 $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # currently have 3.2.5 installed $ npm view esm version 3.2.10 # latest version on the registry is 3.2.10 $ npm install audited 590 packages in 1.515s found 0 vulnerabilities # npm install runs the audit, but updates nothing # already matches package-lock.json $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # esm is still 3.2.5 $ rm -rf node_modules/esm/ # remove it from node_modules $ npm i added 1 package from 1 contributor and audited 590 packages in 1.647s found 0 vulnerabilities # it updated one package this time $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # oh look, matches package-lock.json! what do you know. Now, if you do `npm install esm` or some other _explicit choice to pull in a package by name_, then yes, it'll update it, and update the package-lock.json as well. But that's not what we're talking about. I often don't know what I'm talking about in general, but I do usually know what I'm talking about re npm.
- deleted 8y ago
  [deleted]

gkop 8y ago

Thanks for the reply Isaac! This doesn’t match my first-hand experience unfortunately. Are there any circumstances under which npm install with a lockfile present deviates from the lockfile where npm ci does not? For example, why did this person experience the changing lockfile? https://github.com/npm/npm/issues/17101 https://github.com/npm/npm/issues/17101 Or why do these docs say? > Whenever you run npm install, npm generates or updates your package lock https://docs.npmjs.com/files/package-locks https://docs.npmjs.com/files/package-locks Oh, this seems like what I experienced: https://stackoverflow.com/a/45566871/283398 https://stackoverflow.com/a/45566871/283398 It does appear that npm works somewhat differently than the “obvious” way we would expect package managers to work vis a vis lockfiles :( At least npm ci gets the job done for my use case :)

IsaacSchlueter 8y ago
If you run `npm install` with an argument, then you're saying "get me this thing, and update the lock file", so it'll do that. `npm install` with no argument will only add new things if they're required by package.json, and not already satisfied, or if they don't match the package-lock.json. In the bug linked, they wanted to install a specific package (not matching what was in the lockfile), without updating the lockfile. That's what `--no-save` will do. The SO link is from almost 2 years ago, and a whole major version back. So I honestly don't know. Maybe a bug that was fixed? If this is still a problem for you on the latest release, maybe take it up on https://npm.community https://npm.community or a GitHub issue?

spdionis 8y ago

> Both `npm install` and `npm ci` respect the lock file This is not correct. `npm install` will update your dependencies, not install them, disregarding the package versions defined in the lock file. It feels like you are not getting the point of having a lock file in the first place. It should be obvious that you can't do an install (which npm calls ci) if you don't have a lock file. The lock file represents your actual dependencies. Package.json should only be used to explicitly update said dependencies.

IsaacSchlueter 8y ago
If you run `npm install` with no arguments, and you have a lockfile, it will make the node_modules folder match the lockfile. Try it. $ json dependencies.esm < package.json ^3.2.5 # package.json would allow any esm 3.x >=3.2.5 $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # currently have 3.2.5 installed $ npm view esm version 3.2.10 # latest version on the registry is 3.2.10 $ npm install audited 590 packages in 1.515s found 0 vulnerabilities # npm install runs the audit, but updates nothing # already matches package-lock.json $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # esm is still 3.2.5 $ rm -rf node_modules/esm/ # remove it from node_modules $ npm i added 1 package from 1 contributor and audited 590 packages in 1.647s found 0 vulnerabilities # it updated one package this time $ npm ls esm tap@12.5.3 /Users/isaacs/dev/js/tap └── esm@3.2.5 # oh look, matches package-lock.json! what do you know. Now, if you do `npm install esm` or some other _explicit choice to pull in a package by name_, then yes, it'll update it, and update the package-lock.json as well. But that's not what we're talking about. I often don't know what I'm talking about in general, but I do usually know what I'm talking about re npm.
deleted 8y ago
[deleted]