[BUG] `npm publish` should require `-f` if @scope in npmrc differs from publishConfig

[EvanCarroll]

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

npm publish is not clear about where it's publishing too.

I have a repository that I pulled down with a clone. My local ~/.npmrc file has,

@acme:registry=https://verdaccio-alpha.dev.acme.net/verdaccio/
//verdaccio-alpha.dev.acme.net/verdaccio/:_authToken="TOKEN"

If I run npm publish where does the repository get pushed? From the location in npmrc which hosts the scope? Nope.

It gets published to production because there is a publishConfig entry in the package.json

  "publishConfig": {
    "registry": "https://verdaccio.dev.acme.net/verdaccio/"
  },

This is not what I would expect. And I don't think having two sources for truth on a command like npm publish is a good idea.

Perhaps if the publishConfig entry isn't the same as the scope, we can require --force?

In our case we were setting up a new development box for verdaccio. I thought changing the npmrc would be sufficient but I will also need to scrub all of the publishConfig

Expected Behavior

I would expect it to require -f as the assumption that I was aware publishConfig was set is not sound.

Steps To Reproduce

1. Create an npmrc file which sets scope
2. Create a package in scope
3. Set publishConfig
4. Observe publishConfig is taken and scope is ignored.

Environment

~/angular-ui # npm --version
8.1.3
~/angular-ui # node --version
v17.0.1

[EvanCarroll]

To put it another way which is even more devious, npm unpublish targets the local publishConfig which means you can destroy a package in a different repo depending on the directory you're in.

[juanpicado]

Hi @EvanCarroll ! me again.

By using publishConfig as the documentation says (maybe it could be more explicit) https://docs.npmjs.com/cli/v7/configuring-npm/package-json#publishconfig has precedence over .npmrc or --registry. It also described here https://verdaccio.org/docs/cli-registry/#npm-5x-6x because is quite a popular question and creates a lot of confusion. Same happens in other package managers as pnpm or yarn.

Usually npm unpublish is not an issue in npmjs since is not easy to unpublish but this can easily happen on other private registries (unless you forbid it) as you are experiencing now.

There is no easy answer, My personal taste is don't use publishConfig and rely more on --registry or on in some CI .npmrc file if I need the token as you have above

[ljharb]

It’s very important to use publishConfig, since the local user’s registry settings shouldn’t override where the package is published to.

[EvanCarroll]

@ljharb That view breaks all assumptions in CI, where users will have a verdaccio server, or a GitHub or GitLab registry.

Let's say a user forks a package @github/foo. When they publish they will almost certainly NOT be able to publish to npm's @github/foo nor will they likely have they the access rights to publish to @github/foo. What they will want to do is publish to their own private registry, that's not every instance of publish but that will be the majority of them.

In this particular case the problem is that we have two internal Verdaccio servers. And having a runner configured to publish to testing is not possible without manually ensuring that there is no publishConfig. That's a huge pain, because now they're not changing a configuration file that can be viewed as part of CI, but they're having to change code that checked in and they have to rewrite their package.json.

In my opinion, it would be better to not have publishConfig at all: it's far easier to generate .npmrc for the CI job than to configure publishConfig, and this is what all external tooling suggests. Below is a screenshot from verdaccio, note it does not suggest adding the publishConfig entry.

• GitLab's CI instructions for NPM, note they're advising people write .npmrc to point to a new repo
• 
• npm publish says nothing of publishConfig

[ljharb]

@EvanCarroll in the fork scenario, they'd need to update the publishConfig as well as part of the forking process. For the "two internal servers" case, I'm not clear on why a package wouldn't always be publishing to the same one?

[EvanCarroll]

@EvanCarroll in the fork scenario, they'd need to update the publishConfig as well as part of the forking process.

There is nothing that needs to be updated as part of the forking process. Requiring this adds work that no one should have to do, the publish location shouldn't be in the code. A shared runner on GitLab and GitHub can lint and test code in forks just fine and publish the result to the local repository if needed. This is relatively normal. Every git repository on GitLab has it's own NPM repository -- you shouldn't have to "configure it" to have your CI magically publish there. Every fork shouldn't have code that redundantly tells it to push to the local NPM repository. You can see how that works at this address. The CI just writes the .npmrc file and everything works. You probably don't want forks publishing to your main repository though.

It's pretty typical for developers to have their own repository where their own forks publish too, at cPanel we use this to communicate builds to QA.

I'm not clear on why a package wouldn't always be publishing to the same one?

Specifically in my case I am migrating over packages that publish to an old Verdaccio, to either (a) a new verdaccio and/or (b) a new GitLab.

This is only a hypothetical: take for example something like @airbnb/config-babel.

• You have a main repo that hosts the code internally at airbnb on GitLab or GitHub.
• A user at airbnb or external to the company forks it it. A CI pipeline may run unit tests to make sure it's internally consistent including linting it's own base or testing it with babel. If all this passes, it may generate a build which they can send around (something they can install with npm install).
• At the end though you may have process at airbnb of vetting this or making sure that this new babel configuration doesn't break other CI pipelines at the company. You may want this to go out officially only after internal processes have been satisfied. So you do not yet (if ever) want this build on your production servers.
• You don't want users to have to configure their CI, you just want it to work on all forks. They can publish whatever they want to their own npm package repo. The CI need only generate the NPMRC from the jobs environmental variables (link above).

What we're doing at cPanel is using the Angular Commit Convention in Git Messages. When you onboard you fork any repo you want to contribute to, write a properly formatted commit message, and the system takes care of pushing to your git repository's NPM repo.

[ljharb]

You're making a lot of sweeping statements that assume that the way Gitlab works is The Way. When a repo is forked, even the package name itself is something you likely don't have access to. You always have to make a series of changes when making a fork for any reason beyond making a PR to the upstream.

CI runs on PRs, or branches, or both, and publishing generally only runs on the main repo's default branch. Since it requires a secret, it would never work on forks in the first place. .npmrc is usually checked in, not generated; but either way you wouldn't want automated publishes on forks.

[EvanCarroll]

You're making a lot of sweeping statements that assume that the way Gitlab works is The Way.

I agree with sentiment, yes -- but it's not just GitLab: I'm stating the way CI works is The Way. These workflows are pretty much the same in any system though. You're not going to want to customize anything you don't have to customize when you fork. It's a sort of conflict of interest too because you're mixing the CICD configuration between package.json and whatever CICD system you're using.

These new CI frameworks are creating repos for you they're inferred from the project name. The assets for the repos are relative to the repo itself. You do not want an absolute URL in your code base to point to the repo, you want everything to relative to the repo's location.

But I also don't think I'm the only one making sweeping statements, consider these past ones ;) :

• "It’s very important to use publishConfig, since the local user’s registry settings shouldn’t override where the package is published to."
• "In the fork scenario, they'd need to update the publishConfig as well as part of the forking process."

When a repo is forked, even the package name itself is something you likely don't have access to.

I'm not sure what that means. If you fork you fork into a different namespace. For example. if I fork npm/cli I fork it into evancarroll/cli. There is no reason why everything else shouldn't work. The repo behind evancarrol/cli can have a package with a name of @npm/cli and .npmrc supports setting the scope npm to point to my private fork. So I'm not sure I follow what you mean when you say you likely don't have access to it.

You always have to make a series of changes when making a fork for any reason beyond making a PR to the upstream.

I am unsure why that is true.

Since it requires a secret, it would never work on forks in the first place. .npmrc is usually checked in, not generated; but either way you wouldn't want automated publishes on forks.

npmrc should never be checked in if it has a secret. That would be axiomatically wrong. You would at the very least store the file protected and masked in your CI system. But I'm not sure why there needs to even be a secret here, it doesn't require a secret to publish if

• GitLab: There is a CI_JOB_TOKEN which will allow publishing to the package repository
• GitHub: There is a GITHUB_TOKEN. (Works the same way, as I understand it.)
• Your developers may have their own repositories which needn't be secured which can simply provide anonymous publication. These can be inferred from the namespace they forked into, in the above example npm/cli to evancarroll/cli -- there could easily be a verdaccio server that allows anonymous publications at evancarroll.verdaccio.acme.com (evancarroll inferred from my CI_USER_NAME)

The system (npm) is not very friendly with GitLab and GitHub CI workflows because it's stepping on their shoes by storing publication locations in the repo, which is in their wheel house of CICD. Just to be clear, these problems all go away if we

• Warn when there is a conflict between npmrc and publishConfig.
• Provide the ability to ignore publishConfig, or to specify the source of truth npm publish --config=npmrc
• Provide a method to invoke npm publish ignore all config files NPM_TOKEN=token npm publish --ci --repo=repo or something.

[ljharb]

Ah, i see what you mean, having a repo-specific registry is unique to gitlab, which is why I’m unfamiliar with it.

[EvanCarroll]

Well, yes. GitLab is amazing! But you don't need that.. I mean you could for example set up a verdaccio server for every team/group/company, and then fork into that namespace... All of the packages inside that namespace can publish to the shared asset there. There is still no reason why customization should be required: so long as you can publish somewhere that can be inferred (by username, team name etc) or configured in your CI (think uploaded .npmrc to gitlab/github as a shared secret).

[ljharb]

I suppose you could, but I've never heard of any company doing that - having two sources of truth for the same package name seems both very confusing, and constitutes a supply chain attack vector, so it's an actively bad security practice. In other words, a package name should only ever have one canonical registry it can be, or is, installed from.

[EvanCarroll]

Git itself is decentralized: it's the very nature of the beast. Is my repo the authoritative is your repo authorative? Is my branch main authoritative or your branch main? How is extending decentralization to a package registry any different? Or, more of a "supply chain attack vector"?

It's a very simply paradigm,

• Every developer gets access to all resources required to develop and deploy.
• Official and trusted deployments happen on repo $x, and package registry $y.

That exploit you provided is contingent on NPM being a trusted authority for unscoped unpublished packages which a malicious third party can publish to. That's totally different. No one can publish to my production at @acme CICD bots running on the main branch. This isn't a problem if you can ensure you do not utilize untrusted sources for packages on trusted machines, and that's easy. But sure, it stands to reason if you say install $thing and $thing can resolve to something different you need to be sure you can control what it resolves to on machines you care about whether that resolution happens with dns, symlinks, package names, etc.