[BUG] NPM tries to install transitive dependency from incorrect registry when scope override is present

[gethinwebster]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

I have an .npmrc with two registries configured:

1. A private registry configured as default (i.e. not scoped)
2. The public https://registry.npmjs.org/ configured for a specific scope @scope-a

I am trying to install @scope-a/package-a, which also has a dependency on @scope-a/package-b.

The install fails, because it tries to fetch the transitive dependency @scope-a/package-b from the private registry instead of the public registry configured for that scope. From the logs, it appears that some initial calls (to get available versions) are made to the correct (public) registry, but then the call to fetch the package content is made instead to the incorrect (private) registry, which doesn't have that package+version, and so the install fails.

Expected Behavior

@scope-a/package-b should be installed from the public registry.

Steps To Reproduce

See above/below

Environment

• npm: tried with multiple versions of 8 and 9, happens for all. The configuration works with npm 6
• Node.js: 14.19.1
• OS Name: MacOS 12.6.1
• System Model Name: Macbook Pro
• npm config:

registry=https://[private-repo-url]/
//[private-repo-url]/:_authToken=[token]
@scope-a:registry=https://registry.npmjs.org/

[gethinwebster]

The problem seems to stem from here:

    // the default registry url is a magic value meaning "the currently
    // configured registry".
    //
    // XXX: use a magic string that isn't also a valid value, like
    // ${REGISTRY} or something.  This has to be threaded through the
    // Shrinkwrap and Node classes carefully, so for now, just treat
    // the default reg as the magical animal that it has been.

So, when we use a non-default global registry, and the default registry for a single scope, that single scope ends up falling back to the configured global registry, which is incorrect in this case.

[gethinwebster]

So, it seems that an undocumented flag has been added to control this behavior. For reference, running npm install --replace-registry-host=never solved this for me.