feat(multiple-dist-tags): add proposal for multiple dist-tags

[wraithgar]

This is a suggestion that grew out of a discussion surrounding #317.

It will afford a way for end-users to set all the dist-tags they want at once, at the time they intend to.

Examples:

$ npm publish --tag latest,next,latest-7

$ npm dist-tag add npm@6.14.11 latest-6,lts

$ npm dist-tag rm npm next-2,next-3,next-4

[ljharb]

Will versions of npm without this feature fail loudly on , in the argument? (i believe so)

[wraithgar]

Will versions of npm without this feature fail loudly on , in the argument? (i believe so)

Good question, no it won't. I was under the impression that dist-tags could not contain values that would url encode but apparently I am wrong. This means we have to either choose the new cli flag approach, or find a syntax that will error out with the current cli, and hopefully current registries.

~/D/n/gar-create-test (main↑4|✔) $ npm dist-tag add @gar/create-test@1.0.0 foo,bar
This operation requires a one-time password.
Enter OTP: ******
+foo,bar: @gar/create-test@1.0.0
~/D/n/gar-create-test (main↑4|✔) $ npm dist-tag ls @gar/create-test
false: 1.0.11
foo,bar: 1.0.0
latest: 1.0.13

ETA: you can also see here the false tag that is evidence of what happens right now if you do --no-tag during publish.

[wraithgar]

Multiple values for the same parameter might be better implemented as multiple declarations on the cli i.e.

npm publish --tag latest --tag lts --tag next

npm tag rm npm next-2 next-3 next-4

[ljharb]

What happens in npm already with multiple tags in those fashions?

[wraithgar]

What happens in npm already with multiple tags in those fashions?

It takes the last one you gave

~/D/n/gar-create-test (main↑5|✔) $ npm publish --tag latest --tag next --tag false
...
~/D/n/gar-create-test (main↑5|✔) $ npm dist-tag ls @gar/create-test
false: 1.0.15
latest: 1.0.13

[wesleytodd]

I have packages with all sorts of weird tags because of accidental typos or bugs in the generated tags. For example "latest" where an extra set of quotes was thrown in on accident. I wonder if some normalization could be done which would prevent further changes from being this difficult? If we did a slugification on tag strings I think it would help prevent bugs/errors and result in a better overall UX despite the fact that it might break some use cases in the wild.

[theoludwig]

In my opinion, it is weird to have the same version with mutiple tags attached to it, version is either stable (latest) or in beta, or in alpha, etc.
I would rather have a better deal with version number and tag, as it is described in #317.
I think that tags and versions number should work together, better relationship between them.

Most of npm packages are using tags (others that the default latest) to get feedback from a small part of users, before releasing for the majority of users, so they can improve the release before publishing it as ready for production in latest.
Is there is any use case for tags, that I'm missing ?

As far as I understand to the issue, we can already publish a version to mutiple tags by doing multiple time the command ?
For example, currently, I want to release my new version to latest, next and canary, I need to do it like so :

npm publish --tag latest
npm publish --tag next
npm publish --tag canary

Is it right ?

As I said, I don't think it's a good idea to publish a version to mutiple tags, but I agree that it's better to do it like that : npm publish --tag latest --tag next --tag canary than the current way to do it.