[BUG] `publishConfig.registry` in `package.json` should take higher priority than project level `.npmrc`

[JounQin]

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

For example, If I have publishConfig.registry = registryA in @scope/foo's package.json, and $cwd/.npmrc with @scope:registry=registryB, when I run npm publish on @scope/foo, I'd expect to publish it to registryA instead of registryB.

However, the current behavior is unexpected to publish on registryB.

Expected Behavior

As title

Steps To Reproduce

As described above

Environment

• npm: 9.8.1
• Node.js: v18.18.2
• OS Name: Darwin arm64
• System Model Name: macOS 14.1.2
• npm config:

; "user" config from /Users/JounQin/.npmrc

//internal-mirrors.alauda.cn/repository/npm/:_authToken = (protected) 
//registry.npmjs.org/:_authToken = (protected) 

; "project" config from /Users/JounQin/Workspaces/Alauda/octopus/.npmrc

@alauda/dp-cli:registry = "https://registry.npmjs.org/"
@alauda/dp-dynamic-plugin-backend-core:registry = "https://registry.npmjs.org/"
@alauda/dp-dynamic-plugin-frontend-core:registry = "https://registry.npmjs.org/"
@alauda:registry = "https://build-nexus.alauda.cn/repository/npm/"

; node bin location = /Users/JounQin/Library/Application Support/fnm/node-versions/v18.18.2/installation/bin/node
; node version = v18.18.2
; npm local prefix = /Users/JounQin/Workspaces/Alauda/octopus
; npm version = 9.8.1
; cwd = /Users/JounQin/Workspaces/Alauda/octopus
; HOME = /Users/JounQin
; Run `npm config ls -l` to show all defaults.

[JounQin]

Also,

@alauda/dp-cli:registry = "https://registry.npmjs.org/"

This does not work to me neither.

[wraithgar]

The project level .npmrc and publishConfig in the package.json are technically of equal priority. They are both "project" level configurations. Having both is not recommended, npm has to pick one over the other and there is no "correct" choice. npm prioritizes the file because it is historically something that folks can have in a project that is overriding things in the project itself. The current way of doing things is intentional and the best attempt of parsing an conflicting setup.

[JounQin]

So no way to publish with correct registry without --registry option?

[JounQin]

The project level .npmrc and publishConfig in the package.json are technically of equal priority.

@wraithgar I still don't understand this statement, other package manager like yarn berry prefers publishConfig.registry over project level .yarnrc.yml, having both configs is absolutely valid usage for multi npm registries IMO. Your statement is just giving up trying to fix the problem which is very disappointing.

https://yarnpkg.com/configuration/yarnrc#npmPublishRegistry

[Kenneth-Sills]

So no way to publish with correct registry without --registry option?

It's a bit worse than that, --registry is ignored if either .npmrc or package.json contain registries that match the package's scope. It's not possible to provide a scoped registry via CLI args AFAIK, and the registry with the highest specificity to the package's scope always wins first. Example:

Click to Open

Assuming a package called @demo/package...

Scopeless

// package.json
{
    "publishConfig": {
        "registry": "https://pkg.fake.io"
    }
}

# .npmrc
registry=https://rc.fake.io

# Command
npm publish $(pwd) --registry "https://cli.fake.io"

# Attempts to publish to 
# https://cli.fake.io

Partially Scoped

// package.json
{
    "publishConfig": {
        "registry": "https://pkg.fake.io"
    }
}

# .npmrc
@demo:registry=https://rc.fake.io

# Command
npm publish $(pwd) --registry "https://cli.fake.io"

# Attempts to publish to 
# https://rc.fake.io

All Scoped

// package.json
{
    "publishConfig": {
        "@demo:registry": "https://pkg.fake.io"
    }
}

# .npmrc
@demo:registry=https://rc.fake.io

# Command
npm publish $(pwd) --registry "https://cli.fake.io"

# Attempts to publish to 
# https://pkg.fake.io

Note that package.json does consistently take precedence over .npmrc as long as their scopes are identical. See the implementation, where it's the last thing flattened into the configs before publishing.

@wraithgar Could you please re-open this ticket and consider canonizing this behavior? This priority is actually critically important for anyone using Gitlab's NPM package registry, since you need to be able to use .npmrc for installing dependencies from your scoped registry and then override that inside package.jsons publishConfig for publishing dependencies... Gitlab requires you to install from the instance-wide endpoint and publish via a project-specific one.

[thierrymichel]

Any news on this ?

I need to publish my package in a Gitlab private registry at a project level.

I put this in the package.json for publish only.

"publishConfig": {
    "@private/registry": "https://registry-at-project-level"
  },

but this package use other packages at a group level (same private registry, sibling project).

So I need .npmrc to be able to install packages…

@private:registry=https://registry-at-group-level

This does not work.

Even if I use --registry argument with the CLI 😭