Make npm i --no-save default when there is no argument


(Daijiro Wachi) #1

As we already notice around this topic reported from community, a behaviour of npm install can be a bit tricky when it modifies package-lock.json with no argument. Apparently, yarn also had the same behaviour but they changed it and it seems to be a good practice.

As an idea instead of bug report, could we try the same thing in npm? The bare minimum change in the code base can be just one line like this:

// right before making new instance of Install in install function at lib/install.js
if (!args.length) npm.config.set('save', false)

Related links:


(Maximilian Berkmann) #2

It used to be like that, I still remember when running npm i ... would only install a package in the node_modules directory without affecting package*.json.
I can see the benefits of having the --save as the default but --no-save is preferrable.


(Roy R ) #3

But npm clean-install / npm ci is better for that anyway.


(Daijiro Wachi) #4

Yes, that’s correct. Both works for the case. The thing is about which behaviour would be good practice as the default behaviour of npm install in term of UX. As an example, if end user clone a repository and run npm install without argument immediately makes a diff for package-lock.json, it’s expected or now. Plus, how frequently it could happen. It can be a very high rate.

According to the reported suggestions and my opinion, just running npm install should not change package-lock.json.


(Daniel Stockman) #5

Yarn has two separate commands, add and install; npm has one (alias, sure, but not a separate code path), therefore the analogy isn’t applicable.

More importantly, you would be breaking the folks who manually edit dependencies and then run npm install. I know those sorts of operations are better with commands, but I’ve been trying to convince folks at my company to use the commands for several years now, and the manual editing persists.

If the lock file and manifest are in sync, npm install shouldn’t be making and changes anyway. I don’t think defaulting to --no-save is the way to fix those bugs.


(Daijiro Wachi) #6

That is interesting! Thank you for the specific use case.

I think the below part is what we may want to clarify which dependency tree should be taken priority.

More importantly, you would be breaking the folks who manually edit dependencies and then run npm install

I still believe that package-lock.json should always be correct even it’s not in sync with package.json. Otherwise, every time users run npm install, package-lock.json is not used as the first place.

However, if there are no package-lock.json and users run npm install, they would expect that npm will generate package-lock.json file. Let me write down the steps that I think of the most expectable behaviour:

package-lock.json exists

  1. If a new package will be added through command line arguments
    1. Generate a new dependency tree
    2. Install packages
    3. Overwrite package-lock.json
  2. If there are no command line arguments
    1. Install packages
    2. Check if package-lock.json is no in sync with package.json
      1. If it’s not, display a warning to inform users about it

package-lock.json does not exist

  1. Generate a new dependency tree
  2. Install packages
  3. Overwrite package-lock.json