[BUG] npm v1.3.0 regression with custom registry

[Badisi]

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

When using a custom registry url with sub paths, npm 1.3.0 construct malformed urls whereas 1.2.0 was fine.

Consider the following:

# package.json
{
  "name": "test",
  "dependencies": {
    "lodash": "^4.17.21"
  }
}

# package-lock.json
{
  "name": "test",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "name": "test",
      "dependencies": {
        "lodash": "^4.17.21"
      }
    },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==",
      "license": "MIT"
    }
  }
}

Now create an .npmrc file and specify a custom registry:

# .npmrc
always-auth=true
registry=https://my-registry.com/repository/npm-all/
//my-registry.com/repository/npm-all/:_authToken=NpmToken.abcdef

And run the following:

npm install

with npm 1.2.0

Everything will install without issues

with npm 1.3.0

The following error will occur:

npm error code E404
npm error 404 Not Found - GET https://my-registry.com/lodash/-/lodash-4.17.21.tgz
npm error 404
npm error 404  'zone.js@https://my-registry.com/lodash/-/lodash-4.17.21.tgz' is not in this registry.
npm error 404
npm error 404 Note that you can also install from a
npm error 404 tarball, folder, http url, or git url.
npm error A complete log of this run can be found in: /Users/test/.npm/_logs/2025-04-15T17_11_15_005Z-debug-0.log

We can clearly see that npm 1.3.0 is re-using only the domain url and not the complete registry url:

• ie. https://my-registry.com/lodash instead of https://my-registry.com/repository/npm-all/lodash

Environment

• npm: 11.3.0
• Node.js: v22.12.0
• OS Name: macOS Sequoia

[milaninfy]

@Badisi Thank you for filing this. As a workaround you can still use 11.2.0.
This is fixed by #8222.