Alias `--tag` to `--channel`

[pygy]

git tags and npm tags are often concomitant concerns, and having the same term for both causes unnecessary confusion.

In common parlance, npm tags are refered to as release channels, it would be nice if that was reflected into the cli options, with a --channel that would alias to --tag.

[ljharb]

Where is this term “commonly” used?

[pygy]

Here are the relevant hits on duckduckgo when you search for "release channel".

https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels https://docs.expo.dev/distribution/release-channels/ https://reactjs.org/docs/release-channels.html https://support.google.com/chrome/a/answer/9027636?hl=en https://developer.oculus.com/resources/publish-release-channels/ https://docs.microsoft.com/en-us/officeupdates/current-channel https://docs.microsoft.com/en-us/windows/deployment/update/get-started-updates-channels-tools

These are all on the first page. It is broadly used in the industry, and fairly well understood by users.

Firefox also has release channels. Almost any Web dev is already familiar with the term used for this meaning. It is more meaningful and specific than tag.

[ljharb]

A release channel is a common concept for particularly large projects. However, npm tags - and git tags - are both used quite commonly not for that, and also both used for that. This alias would be confusing.

npm's command is dist-tag, so the only alias I think would make sense here is dist-tag.

[pygy]

Large projects appear on the first page of search results.

Channels are used by projects of all sizes.

I'm not saying tags are not used for other scenarios, but I haven't seen any in the wild (though I'd love to see common examples of other uses).

It's funny you compare git and npm tags, as they are nothing alike. npm tags map to git branches, npm versions map to git tags or commits.

edit: clarity

[ljharb]

I maintain over 300 projects that use git tags and npm tags, and don't use the concept of "release channels" whatsover.

The concept basically does not appear at all outside of large projects.

npm tags map to an npm package tarball, not to anything about git whatsoever. git tags map to a git sha, which might be a branch, or not.

[pygy]

git branches are mutable pointers to the growing end of an append-only¹ list of immutable² commits.

npm tags are mutable pointers to the growing end of an append-only³ list of immutable⁴ versions.

These may look very different at a glance, but if you squint a bit and blur the lines you'll see these graphs commute.

In well maintained packagesnpm versions gets a matching git tag (at least on the latest tag).

The smallest packages have a single release channel: latest... What I'm curious about is uses of npm tags that are not used as such, i.e. labelling streams of releases intended for specific audiences.

---

^{1, 2, 3, 4} caveats apply

---

Edit: I'm being told that I must be more explicit in my wording... Could you provide examples of common uses of npm tags that aren't release channels, as defined above?

[ljharb]

Your definition establishes that everyone is using release channels. But that’s simply not true - i have over 300 projects that do not employ that concept and for which i do not use that term, and for which npm tags are simply not used in that fashion. I even have packages where i backport to multiple minors and majors, and delete the npm tags once I’m done - there’s no such concept for me as “release channel”.

[pygy]

First...

i have over 300 projects

Adding to the fact that you are a npm CLI maintainer, that makes you a big outlier in terms of package release experience. It doesn't mean your experience and use cases should be discounted (especially given the value these pacakges provide), but it means that they are far removed from the ones of typical users.

Release channels as streams of releases for specific audiences is not my invention, it is an industry-wide accepted definition.

Semver and semver queries (^x.y.z) let users define such streams implicitly (they can be tracked manually or automatically).

When you bump z in x.y.z you are publishing to the x.y release channel, and depending on whether y is the latest point release, to the x release channel. You may not think of them as such, but the underlying pattern is present, both at the producer and the consumer end.

npm however, will not let you publish packages without associating an explicit dist-tag. So you create a temporary one then delete it. This is sub-optimal.

A --no-tag (or --no-explicit-channel) option and saner defaults when publishing would IMO better serve that scenario. Few package authors who publish, in that order, 1.0.0, 2.0.0 then 1.0.1 want to end up with the latter as latest.

I've also looked a bit into the origins of dist-tag. I don't know why the term was chosen for npm, but searching the Web let me to another use of "distribution tags": in the Linux package management world. In that context, however, tags are IIUC static and immutable, they map to specific distro versions (or to the set of all versions at a given time, but not to the latest value of a stream, or the stream as a whole). Referring to release streams as "distribution tags" is a npm idiosyncrasy.

It is also seldom used. Most users will never publish a package. Most package authors only publish to latest. In these cases, you're not exposed to --tag at all.

The --tag flag becomes relevant for packages that have an audience that's either still tracking older versions, or who wants to dip into alpha or beta testing with little fuss.

Package authors who reach that mile stone generally first clobber latest with what the wanted to publish on the side. They are then made aware of --tag by users (or scour the docs or stackoverflow), and fix up the mess. I've witnessed this several times. Then they use it either once (for a bug fix backport) or for a while (for a beta channel). Then they forget about it, and goof again on the next release (it's happened to me to mis-release like that even though I knew about the option, I'm quite absent minded).

As far as I'm concerned, I use it rarely, and it took me an inordinate amount of time to permanently memorize the flag name, because "tag" in my mind is strongly tied to immutable refs, since that what they are in practice in git (and git tags are more in your face as a dev/author, e.g. in the GH UI, or when you publish a package version).

I knew the option existed, but I could never recall its name, the static/stream contrast creates dissonance that's hard to overcome. After a while, I got it to come intuitively, but then doubt crept in and I had to double-check.

This learning experience is sub-optimal and could be improved. I'd be surprised if I was the only one.

--channel / --no-explicit-channel has the advantage of being widely understood, and doesn't trigger cognitive dissonance like --tag does. With saner publish defaults, it would greatly improve the CLI UX and its learnability.

[ljharb]

I agree a --no-tag option would be ideal; there's an RFC for it.

That said, I don't agree that the concept of release channels is widely understood. node has them, and users are constantly confused about what they are and how they work.

(Git tags are 100% mutable; that they're used immutably in practice is irrelevant)

[pygy]

Beside mathematical constants, everything is 100% mutable. Immutability is approximated by social, physical or computational constrains that can be bypassed with sufficient power.

How git tags are used in practice is very relevant to how people perceive them, yes.

In npm-related projects 99%+ of the time, tags are used to point to commits that correspond to npm releases, which are ~immutable (for the common dev). That's an implicit social contract that is very well respected.

[pygy]

So, beside your use case which uses --tag to mean --no-tag, what uses are there for npm --tag, beside release channels?

[ljharb]

The most common usage is a “next” tag, which is a version that is in the same “conceptual” release channel, but isn’t ready for broad usage, but isn’t a prerelease. These authors aren’t thinking about release channels at all - that mental model is an extreme rarity among package authors.

[pygy]

Now that's interesting.

I would have thought of next as a distinct release channel intended for testing the waters, with no correctness, stability or often even b/w compat guaranties, where latest is the stable release.

They are two distinct streams of releases, for distinct purposes (which coincide when next finally becomes stable).

How do you put next and latest in the same conceptual release channel?

[ljharb]

By just “doing that”. There’s no such thing as a “release channel” concept in npm, as I’ve been saying. You can choose to use npm tags to encapsulate release channels, but that’s something you’re imposing - it’s not part of the inherent model. Most users, i argue, don’t understand that concept at all, let alone apply it to npm tags.

In other words, even if adding any alias would be worth it (it wouldn’t), this one in particular would be far more confusing for most.

[pygy]

Re. "by just doing that", that's begging the question.

We'd need to survey users to get a definitive answer, but I think you underestimate folks out there. You have a broader following that I have on Twitter, would you mind posting a survey:

Do you think of npm "latest" and "next" tags as release channels?

yes no I don't know what a release channel is

[pygy]

Fourth option

I don't know what a npm tag is

Twitter has 25 character limits for poll options. I went for "npm tag"? never heard... and "release channel"? Eh?.

I encourage you to post as well (or RT https://twitter.com/pygy/status/1528781062217900036), you'll get a broader sample, and our respective audiences probably share our biases.

[nlf]

npm has called them tags since the very early days of npm, what you're asking for here is essentially an introduction to a completely different release model than we have used and fostered over the years.

that's not to say that we won't do something like this, release channels might be a thing we want to support in the future, but as of today we're sticking with --tag.

if you'd like to start the conversations to support release channels, please open an RRFC issue at https://github.com/npm/rfcs and see the README in that repo about our weekly public rfc meetings where you are very welcome to join and discuss with us!