Prevent accidental backwards publishing of latest

(Rhys Arkins) #1

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 1.4.0 to 2.0.0 and 2.0.0 becomes latest (expected)
  • Package author publishes 2.0.1 which becomes new latest (expected)
  • Package author backports the fix and publishes 1.4.1, and it takes over as latest (unexpected)

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 --tag, e.g. npm publish --tag latest if they really do with to roll back latest, or npm publish --tag 1.x for example if they wish to avoid this accident.

Or in summary:

  • Running npm publish for a version that is less than the currently tagged latest should be rejected unless --tag is explicitly provided

(Mark) #2

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 latest.

(Qix) #3

Further, setting dist-tag seems to lag quite a bit.