RFC: No implicit tagging for non-latest release versions

[kytta]

First reported in https://github.com/npm/npm/issues/13248 and https://github.com/npm/cli/issues/7553, this RFC proposes changing the behavior of npm publish by disallowing publishing pre-release versions under the latest tag (implicitly). This RFC also tackles the not-yet-implemented behavior for the non-latest release versions (e.g. backports).

References

Related to #26 and RFC 7

Directly relates to https://github.com/npm/cli/issues/7553

[wesleytodd]

I am a big plus 1 on this change, but I dont think this repo is the best place to discuss anymore.

[wraithgar]

Added a link to this in the v11 roadmap. This would be a breaking change. I also like that it suggests just erroring instead of trying to come up with some alternate default tag or guessing one for the user.

[ljharb]

I will be very ecstatic if npm v11 obsoletes https://npmjs.com/safe-publish-latest :-D

[davidlj95]

Agree that it's a better default to avoid instability 👍

Expanding on use cases of marking prereleases as latest, what about when a package has no stable release yet?

Packages are recommended to start at 1.0.0 if using SemVer as 0.x rules are pretty different. For instance:

• npm init creates a package.json with 1.0.0 by default
• Semantic Release doesn't support 0.x versions

In that scenario, how can we first get some feedback from users before actually releasing 1.0.0? Seems pre-releases are a good fit. Therefore you start publishing alpha and beta releases until everyone's happy about a 1.0.0 release.

I think in that scenario it makes sense the default of npm publish is to add the latest tags to every new alpha (and later beta) release.

Otherwise, I guess one could also use alpha and beta channels to publish releases in there. But users would have to do npm install pkg@alpha and npm install pkg@beta. Which indeed is more explicit about the state of the package. But state of the package can also be properly stated in docs.

I think for first pre-releases, users could be instructed to do npm install pkg as usual. latest would point to last pre-release. And at the point the first stable release, they'll get only stable releases. Kind of a way to: install a pre-release until first stable release is ready.

WDYT?

In rest of scenarios (a first stable release 1.0.0 exists) totally agree that latest shouldn't be the default for pre-releases

[kytta]

Expanding on use cases of marking prereleases as latest, what about when a package has no stable release yet?

I think there is a big difference between 'unstable' and 'pre-release', and I personally think that this RFC should only tackle the latter.

Packages are recommended to start at 1.0.0 if using SemVer as 0.x rules are pretty different. For instance:

Semantic Release doesn't support 0.x versions

In that scenario, how can we first get some feedback from users before actually releasing 1.0.0? Seems pre-releases are a good fit. Therefore you start publishing alpha and beta releases until everyone's happy about a 1.0.0 release.

This is unfortunate. This is something I didn't know and haven't considered. I must say that I myself do not use Semantic Release, and I have always been using 0.x versions for unstable APIs.

I think for first pre-releases, users could be instructed to do npm install pkg as usual. latest would point to last pre-release. And at the point the first stable release, they'll get only stable releases. Kind of a way to: install a pre-release until first stable release is ready.

WDYT?

I personally am rather against this. This adds just way too much complexity to what should be a bare-bones setup. The logic behind npm publish should be explainable in a simple sentence, without too many edge cases. Everything else should better be handled by more sophisticated tools, be that np or semantic-release.

I'm interested what the others think, though :)

[wraithgar]

I personally am rather against this. This adds just way too much complexity to what should be a bare-bones setup.

100% agree here. This is currently solving one valid problem in a very straightforward way. Let's keep it on task.

[wesleytodd]

I agree keeping it focused on prerelease for stable lines is a good decision, but just to be clear this means we are agreeing on "no carve out for special behavior on pre-1.0.0" right? I just felt like the above comments might have been a bit unclear as to what specifically folks were agreeing to.

[ljharb]

To be clear, pre-v1.0, a breaking change increments the first or second number when the first number is zero, and any of the three numbers when the first two are zero, so “special behavior” would be anything that deviates from that - ie, from the way carat works.

[wraithgar]

no carve out for special behavior on pre-1.0.0" right

Yes. We are only looking for pre-release tags here. They are a VERY clear signal that this is not a release. It's what it says on the tin.

[ljharb]

The OP includes:

This RFC also tackles the not-yet-implemented behavior for the non-latest release versions (e.g. backports).

I think both are valuable to solve together.

[kytta]

I'd summarize it like this:

This RFC tackles a big footgun of npm publish: publishing something you think others will not automatically get, but they do get it. This applies to both pre-releases and older versions (backports) being automatically tagged as latest without any hesitation.

Special behaviour for 0.x versions (vs. 1.x) is not a footgun, but a preference, so it should not be addressed by this RFC (or probably any npm RFC, for that matter)

[wraithgar]

Great summary @kytta