[BUG] "npm publish" tags pre-versions as "latest" about cli HOT 8 CLOSED

Because this is not a bug I am going to close this issue. The rfc issue is probably the best place to add more input. Personally I'm a huge fan of this idea.

from cli.

failing and forcing a tag seems nice. even better is if it implemented https://npmjs.com/safe-publish-latest, and failed to implicitly publish a latest whenever the version being published isn't a non-prerelease that is "later" than all existing versions.

from cli.

If they explicitly want something to be "latest" then it would be wildly improper for npm to prevent that, but it seems reasonable to me that implicit "latest" must always be a "later" non-prerelease.

(to be clear, this is something that'd have to be accepted by the npm team, and probably should be discussed in the RFC repo instead of here)

from cli.

So, this behaviour, then?

npm version 1.0.0
npm publish # no problem

npm version 1.0.1-alpha.1
npm publish
# npm ERR no tag set

npm publish --tag alpha # no problem

npm version 1.0.1-alpha.2
npm publish --tag latest # no problem; set implicitly

npm version 0.1.0 # assuming it's possible
npm publish
# npm ERR a newer 'latest' version is already published

Another question. What should we do about this behaviour:

1. developer willingly publishes a pre-release to latest (npm/npm#10189 (comment))
   • say, 1.0.0-rc.1 => latest
2. developer makes a new pre-release version with the same version number (major.minor.patch), and a different pre-release identifier combo
   • say, 1.0.0-rc.2
3. developer runs npm publish

Should we allow this, because the developer "opted-in" to publishing pre-releases for 1.0.0 to latest (in other words, because the current latest is also a pre-release), or should we always require an explicit tag for pre-releases?

from cli.

If they explicitly want something to be "latest" then it would be wildly improper for npm to prevent that, but it seems reasonable to me that implicit "latest" must always be a "later" non-prerelease.

Sounds good. It also matches the behaviour proposed in RFC 7

(to be clear, this is something that'd have to be accepted by the npm team, and probably should be discussed in the RFC repo instead of here)

Thanks for the heads-up! I've drafted one here: npm/rfcs#776

from cli.

➕ 1 on failing when not passing an explicit --tag for prerelease versions. This has bitten me so many times over the years and has contributed to my beliefs automated publish workflows are superior (despite the tradeoffs). This would remove one of the rough edges around manual publish workflows and seems pretty clearly to be a good thing.

from cli.

Some tag must always be set - what tag would you expect as an alternative?

from cli.

Some tag must always be set - what tag would you expect as an alternative?

If not failing for pre-release builds (which would force the user to set the tag), I'd choose either:

• next for any semver-compliant pre-release version, or
• the tag that matches the prerelease suffix, if there is any. For example, 2.0.0-alpha.1 would get the tag alpha, 2.0.0-rc.3 would get the tag rc

from cli.