[rush-lib] Update [dot]npmrc #5296
Conversation
Co-authored-by: Ian Clanton-Thuon <iclanton@users.noreply.github.com>
|
The repo maintainer generally wants to control which registry the repo talks to explicitly, so overriding whatever the user has configured is the desired behavior. For example, this repo explicitly uses the public registry because it's an OSS project. If a developer has a private registry configured that does not have the public registry configured as an upstream and runs |
|
@iclanton The public npm registry (https://registry.npmjs.org/) is the default registry for all standard npm and pnpm setups. Unless a developer has explicitly changed it, it will be used automatically. Hardcoding it provides no additional benefit. |
|
The additional benefit is the repo owner ensuring that an individual user's override isn't used. |
|
@iclanton But doesn't it introduce even bigger problems? Users typically won’t notice this configuration after generation, but they’ll have to spend time later figuring out why things are failing. Usually, every company has its own registry, which means as long as they run this command, they’re guaranteed to run into issues. |
| @@ -24,7 +24,7 @@ | |||
| # | |||
|
|
|||
| # Explicitly specify the NPM registry that "rush install" and "rush update" will use by default: | |||
| registry=https://registry.npmjs.org/ | |||
| # registry=https://registry.npmjs.org/ | |||
There was a problem hiding this comment.
🤔 There was originally some reason why this was needed, maybe for Azure DevOps? I will ask some other maintainers about it at Rush Hour tomorrow.
There was a problem hiding this comment.
Actually I think the problem is like this:
1. Person A has no ~/.npmrc user file on their computer. They run rush update --full, so the pnpm-lock.yaml file is created using versions from registry=https://registry.npmjs.org/. Let's say this is the correct behavior.
2. Person B is working in some other repository, where they are instructed to configure a private registry in their ~/.npmrc user file.
3. Next, Person B clones the monorepo and runs rush install. It mostly works, because the private registry has most of the same packages as npmjs.org. But a few versions are missing, maybe because a security policy delays syncing of very new versions.
4. Thus, for Person B, rush install prints a confusing error about missing versions. Why is it broken?
5a. Person B asks for on call support. Person A tries to reproduce the error, but "it works fine for me" (because they are missing the .npmrc file).
- OR -
5b. Person B "fixes" the problem by running rush update --full. Now the lockfile matches their registry. But when they create a pull request, it fails in CI, because the CI machine has no ~/.npmrc user file. What??
The core problem is that rush install is not behaving deterministically. Ideally there should be no ~/.npmrc at all, but 90% of the common problems can be avoided by explicitly specifying registry= in common/config/rush/.npmrc.
Of course, having the wrong default in common/config/rush/.npmrc will also cause confusion, but that's still better than nondeterministic errors.
There was a problem hiding this comment.
Users typically won’t notice this configuration after generation, but they’ll have to spend time later figuring out why things are failing. Usually, every company has its own registry, which means as long as they run this command, they’re guaranteed to run into issues
@L-Qun The problem you're describing here, it only happens when someone is creating a new monorepo, right?
There was a problem hiding this comment.
@octogonz Creating a new subspace
Since
https://registry.npmjs.org/is already the default npm registry, there's no need to configure it explicitly. Otherwise, it will override the user's local configuration