Would node@lts be a good or bad idea?

[yarthur]

Node has this unique versioning scheme where the even-numbered major releases are long-term-support and the odd numbered major releases are the "in-development" versions. I tend to stick to the LTS versions, assuming they're more tested out and stable, and I don't want to worry about my projects breaking due to various moving pieces.

While at the moment I'm perfectly able to brew install node@14, and then every year change that when the new versions are released, it would be extremely convenient if I could run brew install node@lts. This also would match the pattern available through the Docker containers.

I don't have the first clue as to what this effort would be, but I'd be happy to take a stab if someone could point me in a good direction (and it wouldn't be a massive undertaking to get started as a beginner). And apologies if this has been brought up before; I tried searching around a bit, but didn't find anything.

[carlocab]

This is probably as simple as adding a symlink node@lts that points to the right Node formula in the Aliases directory in homebrew/core.

The symlink might have to be called node-lts, though, as the @ followed by no version number might confuse brew. Feel free to open a PR for this so it can be reviewed.

[Bo98]

I seem to recall a similar suggestion coming up before. A concern raised at the time is that it might end up being more confusing than just the plain version numbers, because "LTS" can refer to Node 10, Node 12 or Node 14. It also raises the question of regarding other formulae - should we be doing the same for them?

If you want to raise the discussion again, the best way to do so is a pull request as you can get multiple maintainers to give their thoughts.

[yarthur]

I didn't think to check PRs (I only checked issues and here). I'll dig in there a bit, just to see. If I don't get anything out of that, though, I'll give it a throw.

[mverrey]

Sorry if this opens a can of worms, but having the default version of Node be odd-numbered seems to violate the rule, "Unstable versions (alpha, beta, development versions) are not acceptable for versioned (or unversioned) formulae."

This may sound like nitpicking, but there are widely used downstream projects like Karma that have not been updated to work with Node 15, under the odd/even rationale. As a developer, it's frustrating to have to micromanage that dependency because two parties can't agree on a definition of "stable." Apparently this is also complicated by Node 14 not being able to run natively on Apple silicon.

[SMillerDev]

Node specifies 15.x as the current version and there is no indication that it is unstable as far as I can tell. It isn't a LTS release, but that is not the same thing.

[carlocab]

Apparently this is also complicated by Node 14 not being able to run natively on Apple silicon.

node@14 has an Apple Silicon bottle, so it should be running natively. There are only two formulae that depend on it, though, so it may well be the case that it doesn't actually work properly. However, no one's complained about it.

[ianzone]

brew install node installs the latest node.
brew install node@lts installs the latest node LTS.
make sense to me.