3 ms·

You have to run npm ci instead of npm install to get npm to respect the lock file. I don’t consider that remotely obvious. And this feature was just added to np

by gkop 8y ago

You have to run npm ci instead of npm install to get npm to respect the lock file. I don’t consider that remotely obvious. And this feature was just added to npm last year, 8 years after npm was invented!

IsaacSchlueter 8y ago
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]

by gkop 8y ago

IsaacSchlueter 8y ago

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]