-
Notifications
You must be signed in to change notification settings - Fork 3k
"npm publish" tags pre-versions as "latest" #13248
Comments
As a temporary measure, I have created this package: GitHub: https://github.com/scott113341/npm-publish-safe-latest 😄 EDIT: Use |
👍 Yes, very unintuitive, especially if you've never worked with dist-tags before. We at the Bootstrap Core Team have gotten shot by this footgun: twbs/bootstrap#18520 |
One other thing I discovered:
|
I totally agree. Users should not get prereleases by default. The point of prereleases is to be before a release so if the author is publishing a prerelease they usually don't want their community to get it by default until more testing has been done with that prerelease. By allowing prereleases to become the default when the user doesn't specify the version, npm is encouraging huge instability in codebases using npm. |
Even better if npm would pick up the first dot-delimited identifier from the Semver prerelease and if it starts with a letter use that as the dist-tag, since that's a common standard for use in Semver: 1.0.0-alpha.1, 2.1.3-beta.2016.12.24 for dist-tag alpha, beta respectively. |
We're closing this support issue as it has gone three days without activity. The npm CLI team itself does not provide support via this issue tracker, but we are happy when users help each other here. In our experience once a support issue goes dormant it's unlikely to get further activity. If you're still having problems, you may be better served by joining package.community and asking your question there. For more information about our new issue aging policies and why we've instituted them please see our blog post. |
No one replied to him… |
@othiym23 Could you please reopen this and re-tag it as not a |
@cvrebert My employment with npm, Inc. was terminated as of January 12 of this year, and my rights and responsibilities for managing this project ended at that time. You'll have to find somebody else to ask. |
If anyone is looking for a way around this, check out the |
The only real alternative to this is using np, right? I've published an unsecure, alpha release to thousands of users because of this issue that no one from npm ever bothered to check. |
I'm opening this issue because:
What's going wrong?
Running
npm version premajor && npm publish
will tag the premajor version aslatest
by default. I confirmed this happens when running all pre-release options:premajor | preminor | prepatch | prerelease
.(I was not able to verify the behavior resulting from the
from-git
option due to an error:Error: Version not changed, /Users/scott/.nvm/versions/node/v6.2.2/lib/node_modules/npm/lib/version.js:92:47
. This happened when my most recent commit's tag was set tovX.0.0-0
,vX.0.0
,X.0.0-0
, andX.0.0
, whereX
was a version number that was greater than all other previous versions. This may be a separate issue, or I was doing something wrong.)As @iarna pointed out in #10189, there are valid reasons that authors would want to tag pre-release versions as
latest
. However, I think that this is not good default behavior (though it is documented: "Publishing a package sets the latest tag to the published version unless the --tag option is used. For example, npm publish --tag=beta.")Semver documentation states:
Source: http://semver.org/#spec-item-9
I propose that the
latest
tag only be set if the version to be published is not a pre-release version. I am happy to do the work on this and submit a PR, but I'd like to first discuss and get approval before putting the time in.Thank you for your hard work on npm!
How can the CLI team reproduce the problem?
From https://www.npmjs.com/package/@scott113341/testo
supporting information:
npm -v
prints:3.10.3
node -v
prints:v6.2.2
npm config get registry
prints:https://registry.npmjs.org/
OS X
USA
The text was updated successfully, but these errors were encountered: