Repository navigation
latest points to Alpha by version managers / nodejs.org points to LTS #67135
Description
With the release of Node.js 27.0.0-alpha.0.0.0 (Alpha), Node.js version managers are interpreting this Alpha release to be latest, for example:
| Node.js version manager | latest |
|---|---|
| GitHub actions/setup-node | 27.0.0-alpha.0.0.0 |
| n | 27.0.0-alpha.0.0.0 |
nvm (nvm install node) |
27.0.0-alpha.0.0.0 |
v27.0.0-alpha.0.0.0 is top of the list in https://nodejs.org/download/release/index.json
https://nodejs.org/download/release/latest/ however lists the latest non-alpha release Node.js 26.13.0. This is in line with the descriptions in:
- https://github.com/nodejs/node#release-types
- https://github.com/nodejs/node#current-and-lts-releases
There are however contradictory descriptions of what "current" means. The phase diagram shows only maintenance / active / alpha phases right now. There is no release line in "current".
Question
Should Node.js revise its definition of latest to match the assumption of Node.js version managers?
n describes its label usage in Specifying Node.js Versions
- lts: newest Long Term Support release
- latest: newest release
- current: newest release ignoring alpha versions
This question was also raised in nodejs/Release#1171 prior to Node.js 27 release.
Activity
aduh95 commentedon Oct 30, 2026
Worth noting that GitHub does not let us define both pre-release and latest tags to GH releases. The simplest IMO would to be to use the latest tag for alpha releases, and forgo the pre-release tag
MikeMcC399 commentedon Oct 30, 2026
Should this go onto the Release WG agenda?
latestfor Alpha releases sounds good to me.Users who prefer a stable release can track
ltsreleases.panva commentedon Oct 30, 2026
latestshould imo never point to an Alpha releaseBrendanBerkley commentedon Oct 30, 2026
MikeMcC399 commentedon Oct 30, 2026
ljharb commentedon Oct 30, 2026
fwiw, the next version of nvm will omit alphas by default. the issue is indeed that listing alphas directly in nodejs.org/dist makes them available as if they're a normal node version.
I'd suggest instead, hosting them like rcs, in eg https://nodejs.org/download/alpha/ - then nobody will get them by accident.
MikeMcC399 commentedon Oct 30, 2026
Moving alphas to a different location would mean that downstream consumers may not get alphas at all. It would for instance stop actions/setup-node from accessing them, unless there is an enhancement done and GitHub Actions haven't in the past been particularly fast in adding functionality.
Whatever is decided, it is going to be a compromise.
ljharb commentedon Oct 30, 2026
The whole point of an alpha is that they're opt in - so downstream consumers shouldn't get access to them without explicitly requesting them.
aduh95 commentedon Oct 30, 2026
Any version is opt in, the idea was to treat them the same as e.g. Node.js 25. Downstream consumers should definitely get access to them (quite different from RCs or nightlies, which indeed are meant to be niche)
MikeMcC399 commentedon Oct 31, 2026
I'm withdrawing this question (which was half-way to being a suggestion to change).
Seeing the documentation issue nodejs/nodejs.org#9254 with the hidden Node.js 27 Alpha documentation, there are probably too many dependencies on
latestnot being an Alpha release.ovflowd commentedon Oct 31, 2026
So if I do nvm install node, the expected is for me to by default get an Alpha version? I'm unsure if that is ideal. For example if I ask npm to install latest version, of idk, Next.js, it won't give me a latest alpha.
Just wondering if this is really intentional to serve Alpha's to the masses? When they're expecting stable builds? Maybe incorrect of me to assume Alpha as not stable?