npm ci --ideally

[fregante]

npm ci is great, but I feel that it would be used more frequently if it had an option to run less-strictly. Currently npm ci requires a lockfile to exist, or else it fails.

❯ npm ci
npm WARN prepare removing existing node_modules/ before installation
npm ERR! cipm can only install packages with an existing package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or later to generate it, then try again.

If it had an --no-strict flag or similar, more people people would use it as a default way of setting up a project, either on CI or locally.

❯ npm ci --no-strict
npm WARN prepare removing existing node_modules/ before installation
npm WARN did not find package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Running regular install

added 695 packages from 363 contributors and audited 695 packages in 20.387s

found 0 vulnerabilities

[ljharb]

If you don’t have a lockfile, you’d use npm install, no?

[ljharb]

npm ci || npm install already does precisely this.

[fregante]

That's a good shortcut, but has 2 issues:

• it outputs an error
• it will run both if npm ci fails for other reasons

[ljharb]

I'm not really clear on why we need a universal command - in a shared config, doing something like [ ! -f './package-lock.json' ] && [ ! -f './npm-shrinkwrap.json' ] && npm ci || npm install or similar is not much extra effort, and in an inline config, you already know if the project uses a lockfile or not.

[fregante]

I can say the same thing about build --if-available. The whole point of shortcuts is to avoid writing all of that code.

[ljharb]

True, but it’s a lot harder to check the presence of a field in a json file from the shell than to check the existence of a lockfile.