Don't update latest when the published version is not the latest

[bajtos]

See https://github.com/npm/npm-www/issues/931 for background.

Some npm modules maintain multiple major versions (e.g. express 3.x and 4.x, loopback 1.x and 2.x, etc.). When we publish a new release in the old version line, npm publish updates the latest tag and thus screws up the information displayed on http://npmjs.org/.

npm/npm-www#931 suggests to use a different tag when publishing an older version. While this is a solution,
it's very easy to forget to change the tag and thus accidentally screw the latest tag.

I am proposing to make the npm client more clever and refuse such requests.

Example assuming express@4.0.0 was already published and we are publishing express@3.0.1:

$ npm publish
# fails, refuses to downgrade latest from 4.0.0 to 3.0.1

$ npm publish --tag latest
# passes, you have explicitly asked for "latest" tag

$ npm publish -f
# alternative syntax introducing a new arg `-f`

---

Another alternative orthogonal to the proposal above is to print some extra help after npm publish downgraded the latest tag.

$ npm publish
...
You have downgraded "latest" tag from 4.0.0 to 3.0.1
If it was not intentional, you can fix the problem by running
the following commands:

  npm tag express@4.0.0 latest
  npm update-readme-field-to-match-4.0.0-version

[bajtos]

A possible workaround which I did not try yet: In the git branch for the old major version, update package.json and add "publishConfig": { "tag": "3.x" }. That way npm publish running in the 3.x branch publishes the package with a correct tag and no extra command-line options are necessary.

[smikes]

Did you try out this workaround?

In the git branch for the old major version, update package.json and add "publishConfig": { "tag": "3.x" }.

I think this may be a duplicate of #4709 , where implicitly changing latest to point to a version that is semver-lower than the current latest would result in an error that could be overridden using --force.

As I note there, it's hard to distinguish between these two commands

npm publish
npm publish --tag latest

But there's already a --force parameter with abbreviation -f, so making

npm publish -f

be an override for this guard is definitely possible.

[othiym23]

We're going to ensure that this is working the way @smikes describes (and also maybe add a publishConfig documentation section to the npm help publish docs). @bajtos, I'm a little uncomfortable making npm opinionated in this way – people's workflows are different, and I'm not sure it's the tool's place to decide on policy about what sets latest, but documenting how to make this happen in package.json in a way that removes the footgun is a good idea.

[bajtos]

@othiym23 thank you for the comment. @smikes' proposal looks good to me 👍, I am looking forward to see it implemented.

Honestly, I don't really mind how exactly this issue is fixed, as long as there is a reasonably easy way to keep the right README version on the website when publishing from an older branch.

[othiym23]

The CLI team has discussed this further, and we've agreed that this is enough of a footgun that it merits adding a warning when a publish happens with an older latest than the current latest, with that error message including a pointer to the npm dist-tags documentation so that the user can fix that up themselves after publish. It doesn't make sense to block publishing (and I really don't want to add more uses of -f / --force if it can be avoided), but I do think a warning is warranted. Thanks for your patience / if you feel like implementing this yourself, it would be most welcome!

[smikes]

Okay. I will take a look at this. Rough spec:

As a module author
I want to publish a backdated version

Scenario:
Given a published module
And current package.json version is semver-less than latest
When I publish a new version with npm publish
Then latest points to the newly published version
And an informative warning is displayed

[vladikoff]

@othiym23 Hey

So we published a few patch releases of bower and now 1.4.2 is "latest" and not 1.6.5
I tried resetting the tags but it is 500ing, what should we do?

latest: 1.4.2
➜  bower git:(master) npm dist-tag rm bower latest
npm ERR! Darwin 15.0.0
npm ERR! argv "node" "/usr/local/bin/npm" "dist-tag" "rm" "bower" "latest"
npm ERR! node v0.10.35
npm ERR! npm  v2.14.8
npm ERR! code E500

npm ERR! Registry returned 500 for DELETE on https://registry.npmjs.org/-/package/bower/dist-tags/latest
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/vladikoff/tmp/bower/npm-debug.log
➜  bower git:(master) 

[othiym23]

The CLI team discussed this again as part of reviewing our feature requests, and the consensus of the team agrees with @bajtos – latest should be monotonically increasing in the common case. We have decreed it an npm Best Practice™. We also agree that using --tag latest is the appropriate signal of intent to override this (I’d -f / --force do fewer things rather than more).

However, while this would be a useful safety check for publishers, it’s not important enough to be prioritized over the work the team has scheduled for the next 6-12 month. Therefore, I’m going to mark this request as patch-welcome and close it, to say that we’d welcome a contribution from the community even though we’re not going to ship it ourselves.

For those who are interested in implementing this, there are two tricky aspects:

1. The publishing code already does a little dance with the registry to determine whether a package exists. It gets back all the metadata necessary in its first request to determine whether the new version to be marked latest is greater than the current latest. This may require a little hacking on npm-registry-client, but the current multi-step process makes this pretty simple.
2. Because of the way that npm’s configuration works, you’ll need to query the specific configuration source (cli) when making calls to npm.config.get: npm.config.get(‘tag’, ‘cli’). Otherwise, you’ll have no way of discriminating between the defaults and whatever’s in .npmrc.

Thanks to all for their patience and time!

[RyanCavanaugh]

@othiym23 This bit us on TypeScript pretty badly - it broke our CI because @types/node@latest got pointed at an old package (4.* instead of 8.*).

It's worse because the publish API doesn't seem to support not updating the latest tag, so we have to undergo a dangerous "publish, then move the latest tag again" operation that can fail if the script is interrupted, as well as making a small window of time where npm install @types/node may fail to grab a "correct" version.

I'd at least like to see API support for not moving latest so we can work around the lack of transactional registry updates.

[tswaters]

Is there something an author can do to fix latest to point at latest if two branches are in use? i.e., 1.x branch and 2.x branch - releasing a new version to 1.x will overwrites the latest tag.... It seems there's no way to modify the tags so is the only way to get latest pointing back to 2.x publishing a patch of 2.x?

Really I think we're missing a key API here -- some way to update a tag to point at a different version. The only way to set a tag is by publishing and without capability to overwrite an install, it leaves authors up the proverbial creek without a paddle.

Publishers should be able to add, modify and remove dist-tags without using the install command.