You can run semantic-release without setting NPM_PUBLISH if you set "private": true in your package.json

I'm very well known with what is possible with npm but that is not the question. The question is about making NPM_TOKEN optional (with maybe a setting like : ignoreNpmToken: true).

The package needs to be published but the credentials are in the global .npmrc (or user, this should not matter). npm will read this and will succeed but @semantic-release/npm will complain about the absence of the token.

At this moment i made it possible with @semantic-release/exec, npm version and npm publish but I like the use of @semantic-release/npm more.

I'm very well known with what is possible with npm but that is not the question. The question is about making NPM_TOKEN optional (with maybe a setting like : ignoreNpmToken: true).

Got it, sorry.

I wonder if we could make this work without introducing a new option. Could we check check if the npm token is configured in one of the .npmrc files that npm is using if no NPM_TOKEN is configured, and not throw an error if a token is found?

Related to this issue: The examples suggest that you can skip publishing to NPM by using the config:

    ["@semantic-release/npm", {
      "npmPublish": false
    }],

but even with this configuration defined, it tries to verify a proper NPM_TOKEN. This feels like something that could be checked and ignore validation if it's set.

I'm always in favor of autodetection with the possibility of escape hatches :)

For example, you can't just check the "_auth" property of npmrc. This is only a basic auth option that is used by certain servers like artifactory. We also work with azure devops streams/feeds and they are configured like this:

always-auth=true
; begin auth token
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:username=[ANY_VALUE_BUT_NOT_AN_EMPTY_STRING]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:_password=[BASE64_ENCODED_PERSONAL_ACCESS_TOKEN]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:email=npm requires email to be set but doesn't use the value
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:username=[ANY_VALUE_BUT_NOT_AN_EMPTY_STRING]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:_password=[BASE64_ENCODED_PERSONAL_ACCESS_TOKEN]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:email=npm requires email to be set but doesn't use the value
; end auth token

when you run npm publish, it gets the token based on your local configuration, correct? I wonder if we can run an npm command that gets the token from NPM_TOKEN or your local configuration and verifies that it works for publishing, without doing the actual publish?

I was looking at npm ping. This promises to do exactly what you are proposing. Unfortunately with our artifactory config on my local machine I already had to kill the process.
A bit more ugly is trying to publish something invalid and search for a 401.

Detecting the different auth options can be tricky in npmrc I think. You could maybe look at the always-auth property there. If its true its probably a configured authentication.

Next to this I think that your current config and NPM_TOKEN is pretty ok. If there is an escape hatch to just skip the check (maybe with a warning message) everyone can use the package no matter the config

could you share the details of the actual error that you run into? since you mention that you are publishing to an internal artifactory, this plugin should be skipping at least most of the auth verification since it only does full verification if publishing to the default registry.

I'm running against this check:

Only enforcing this with default registry could also be an option. It mainly about what your philosophy is with the intended behavior

I wonder why this does not work in your usecase, because the code does check if there are valid credentials for the publish registry and if so the NPM_TOKEN is skipped all together:

Any progress with this issue?

I've just ran into the same thing using Google's Artifact Registry. You use their google-artifactregistry-auth NPM module which updates .npmrc for you, so there's no need for an NPM_TOKEN when running semantic-release.

Just ran into the same issue because Artifactory uses NPM_CONFIG__AUTH or :_auth in .npmrc. This package doesn't handle the NPM_CONFIG__AUTH environment variable (or any of the standard npm environment variables).