Revert policy on unrecognized keys in `.npmrc`

[colinhacks]

TLDR: npm v12 plans to start hard-erroring on unrcognized keys. I strongly urge the team to revert this new policy before the stable release.

I've read the arguments for and against. Ultimately my case is this: the ecosystem-wide churn this has already caused (and will continue causing) far outweighs any benefits the team hopes to gain here.

The .npmrc file has been a neutral ground for package managers to write global- and project-level configs since 2010. Non-npm tools use this to configure various novel/innovative features (e.g. custom resolution modes) and security settings (trust-policy). By blocking these in npm v12, a lot of downstream badness will happen/has happened.

1. Config file bloat. The old npmrc configs need to move some other place. This will forces other tools to introduce their own sidecar registry-config file. Bad DX, and far worse degree of fragmentation than simply mixing keys into a shared file. This change will likely force Nub to introduce a .nubrc instead of being able to use a shared file.
2. Configs are silently dropped. pnpm dropped support for global .npmrc. I would bet many thousands of projects upgraded and haven't realized they've weakened their security.
3. Fragmentation more broadly. pnpm dropped support for non-auth .npmrc entirely and dropped npm_config_ env var support too as part of a (possible vindictive) consolidation on its own config system in response to this change. We were SO CLOSE to having a unified shared config system that worked across all PMs. I find it incredibly sad that this decision has fragmented the ecosystem in this way.

A lot of this was predictable. The pnpm stuff in particular is highly regrettable. Churn like this is bad for users and bad for security.

This trend towards increased fragmentation will only continue if this policy stays in place. I understand these are changes that were implemented by other tools (not npm) but these are predictable responses to this policy, and npm is ultimately responsible.

npm reasoning

I've read the arguments in favor of this change. For the sake of completeness:

1. Security — This new policy has already done more downstream damage (due to config incompatibilities and churn) than any anticipated benefits. Forcing this kind of churn is a security vulnerability unto itself that wasn't properly factored in.
2. Typos — Related to security. Typos are detectable with simple edit distance checks. Warn under some edit distance threshold.
3. Collision — I think the scale ofd the problems caused by collision in .npmrc are far less than the scale of problems that have occurred due to this change. It's also quite easy to enumerate the set of keys supported by alternative tools and warn in specific high-impact scenarios (e.g. minimum-release-age is set but not min-release-age).
4. "Just use package.json / env vars" — Other tools need a system for global registry configs. These recommendations generally only work for project-scoped configs. Other suggestions (env vars + dotenv) fail for similar reasons. It's not reasonable to ask a user to use dotenv for every invokation of pnpm dlx.

Alternatives

Not really a fan of any of these, but I think each of these would partially mitigate the ongoing churn problem.

1. Allow an escape hatch. x- prefixing (x-my-config), dotted namespacing (nub.my-config), proper ini section syntax ([nub]), etc. Anything but the nuclear option. I can think of no reason why npm shouldn't pick one of these as a blessed escape hatch path.
2. Allowlist known pnpm/yarn/bun keys that predate this change. Have an allow-list that I and other PM maintainers can submit PRs against. Add special-cased warnings if need be for overlapping keys.
3. Continue merely warning. This would be great too. Totally valid for npm to warn on unrecognized keys.

[lvzhenbo]

I agree. As Chinese developers, we have long used .npmrc as the repository-level storage location for links to various binary images (such as Electron); this has largely become the de facto standard. Now we have to move these environment variables out of the repository and hand them over to complex system-level environment variable management—this is a change with far-reaching implications.