[rush] Warn about problematic settings in $HOME/.npmrc

[wbern]

Is this a feature or a bug?

• Feature
• Bug

Please describe the actual behavior.
I had package-lock=false in my .npmrc file in my user home directory. I had it in a bunch of other places too, but that did not affect anything (like the rush config directory and the root of the project).

Having this property actually causes pnpm to pick it up and neither generate or modify any lock files whatsoever, both 2.x and 3.x.

This essentially fails a rush install command, and if you delete the lock file and try rush update, rush will tell you that it failed to load the lock file.

If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.
Just put package-lock=false in a npmrc file in your home directory.

What is the expected behavior?
I'd like some kind of warning about this from rush, or that rush forces pnpm to use lock file since the rush logic depends on it today.

If this is a bug, please provide the tool version, Node.js version, and OS.

• Tool: rush+pnpm
• Tool Version: all
• Node Version: all
  • Is this a LTS version? yes
  • Have you tested on a LTS version? yes
• OS: Ubuntu

[octogonz]

A major goal of Rush is to ensure a /deterministic/ outcome. This is not the first time someone wasted time debugging an install failure, and then it turned out to be caused by stray settings in their personal ~/.npmrc file. Let's improve Rush to protect against this.

Design questions:

1. Should rush install report a warning or an error if unsafe settings are found in ~/.npmrc?
2. Should we disable this validation somehow on CI machines (since they are a more carefully managed environment)?
3. What settings are safe to go in ~/.npmrc? In my own file, I don't believe I've ever specified anything beyond authentication credentials.

[octogonz]

Detecting NPM auth credentials is a bit tricky due to the haphazard file format. My current file looks like this:

@example-scope:registry=https://example.registry.com/someorg/api/npm/npm-private/
//example.registry.com/someorg/api/npm/npm-private/:_password=<BASE64JUNK>
//example.registry.com/someorg/api/npm/npm-private/:username=your.email@example.com
//example.registry.com/someorg/api/npm/npm-private/:email=your.email@example.com
//example.registry.com/someorg/api/npm/npm-private/:always-auth=true

Maybe we parse it into a left-hand side (LHS) and right-hand side (RHS) delimited by an = operator, and then check the RHS for the following (allowed) suffixes:

• :_password
• :always-auth
• :email
• :registry
• :username

The registry and always-auth properly belong in the repo's common/config/rush/.npmrc. But the repo's file takes precedence, so it doesn't matter if it's specified locally.

Can you think of any other settings that are known to be /safe/? I'm thinking Rush should complain about anything that doesn't match our list of known-safe settings.

[octogonz]

(The docs could also recommend for people to use the handy npmrc command-line tool, if you need to switch between different repos with different .npmrc requirements.)

[halfnibble]

This happened to me too. I don't even remember adding that config setting!

[octogonz]

The implementation should be quick+easy. But I'd like to hear some opinions about the design.

[wbern]

Another solution could simply be to let pnpm output more clearly that there is a setting from an .npmrc file that is interacting with pnpm, perhaps all npm settings should be shown via pnpm in a list of "values set via .npmrc" without displaying the values. I do think I was very unprepared that pnpm actually took settings from npm, even though it also makes total sense since people likely won't want to make .pnpmrc files as of current writing.