The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
Prevent accidental backwards publishing of latest
npm’s current behaviour is that any stable semver that’s published without an explicit tag will become
latest. This is non-intuitive to many and leads to situations such as:
- Package author updates from
- Package author publishes
2.0.1which becomes new
- Package author backports the fix and publishes
1.4.1, and it takes over as
I think this problem could be prevented if
npm publish is enhanced to detect if a publish would result in “lower” semver
latest version and either (a) warns the user via CLI feedback, like with OTP, or (b) rejects the publish with an error message, and the user has to run it with a
npm publish --tag latest if they really do with to roll back
npm publish --tag 1.x for example if they wish to avoid this accident.
Or in summary:
npm publishfor a version that is less than the currently tagged
latestshould be rejected unless
--tagis explicitly provided
Omg YES! I cannot tell you how many times in the early days of npm where I’ve accidentally ran into the third scenario you’ve described. I’ve since learned but I’m sure this is likely to happen to plenty of others. And the worse part is that once the mistake happens, the publisher wont immediately notice the unintended behavior until its too late. I cant think of any reason why a publisher would ever want an older version of a package marked as
dist-tag seems to lag quite a bit.