Repository navigation
Provide allow-prereleases (or similar) option for Node.js 27 Alpha #1657
Description
Description:
Add an option allow-prereleases, like in actions/setup-python, so that Node.js 27 Alpha can be selected simply using:
- uses: actions/setup-node@v7
with:
node-version: 27
allow-prereleases: trueallow-prereleases should default to false.
Justification:
Evolving the Node.js Release Schedule explains how Node.js has introduced a 6 month Alpha phase for new Node.js release lines. This is important for pre-testing and it replaces the previous system of odd- and even-numbered releases, where only the even-numbered release lines were promoted to LTS (Long Term Support).
For ongoing CI testing during the 6 month Alpha phase, GitHub Actions workflows need to be able to specify a generic version of Node.js 27 without having to update a workflow every time there is a new Alpha release (probably every 2 weeks):
None of the following are currently recognized:
2727.0.027.0.0-alpha
only the explicit 27.0.0-alpha.0.0.0 is working:
- uses: actions/setup-node@v7
with:
node-version: 27.0.0-alpha.0.0.0Are you willing to submit a PR?
No, I won't be able to do this.
Workaround
Specify the exact Node.js Alpha version or latest:
- uses: actions/setup-node@v7
with:
node-version: 27.0.0-alpha.0.0.0Edit: according to the discussion in #1660 latest will be changed to install the latest non-alpha version, so the following will not be a future workaround:
- uses: actions/setup-node@v7
with:
node-version: latestLogs
Run actions/setup-node@v7
Attempting to download 27.0.0-alpha.0.0.0...
Not found in manifest. Falling back to download directly from Node
Acquiring 27.0.0-alpha.0.0.0 - x64 from https://nodejs.org/dist/v27.0.0-alpha.0.0.0/node-v27.0.0-alpha.0.0.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/c05d6fa5-ba28-44d7-91cc-40190b158d8f -f /home/runner/work/_temp/92c81dc9-5787-4156-bc71-a2b3900392cf
Adding to the cache ...
Done
Environment details
node: v27.0.0-alpha.0.0.0
npm: 12.1.0
yarn: 1.22.22
Activity
MikeMcC399 commentedon Oct 30, 2026
I just realized that
node-version: latestpicks up27.0.0-alpha.0.0.0, so if it stays this way, that will enable easily following Node.js 27 Alpha releases.The enhancement suggested here still makes sense though.
I also realized that there is now a mismatch between the definition of
latestby Node.js version managers, and the definition used by Node.js itself, so I've raised that in nodejs/node#67135.Edit: Use of
latestis now covered in issue #1660v-mahabaleshwars commentedon Oct 30, 2026
Hi @MikeMcC399,
Thank you for creating this feature request. We will investigate it and provide feedback as soon as we have some updates.
ci: add Node.js alpha workflow
v-priyagupta108 commentedon Nov 5, 2026
Hi @MikeMcC399, thanks for the detailed request.
After looking into this, we're leaning towards a new
allow-alphainput (defaultfalse) rather thanallow-prereleases. Node.js publishes alpha releases alongside stable releases, while RC, nightly, and V8 canary builds are hosted separately and already have their own syntax (24.0.0-rc.4,24-nightly,24-v8-canary). An input namedallow-prereleaseswould suggest those channels are included as well, soallow-alphadescribes exactly what it does.It would behave similarly to
allow-prereleasesin setup-python: an alpha is only used when no stable release matches the requested version, so new alphas would be picked up automatically until 27.0.0 ships.Exact alpha versions such as
27.0.0-alpha.0.0.0will keep working as they do today.Does this approach cover your use case? We'll update this issue once we've settled on the implementation.
MikeMcC399 commentedon Nov 5, 2026
Hi @v-priyagupta108
Thank you for taking a look at this and for your suggestion!
allow-alphawould fit exactly the need to be able to install Node.js pre-releases according to the SemVer syntax example27.0.0-alpha.0.0.0. Other options, like27-nightlyand27-v8-canaryshould be excluded (these releases use the next version28-nightlyand27-v8-canaryin any case). There are no more new27-nightlyand27-v8-canaryreleases anymore.Possibly though,
allow-prereleasescould be used to select any version which is a prerelease according to the Semantic Versioning Specification (SemVer). This would include27.0.0-alpha.0.0.0and then later27.0.0-rc.1for example.Node.js Alpha releases are posted to https://nodejs.org/download/release/ whereas RCs releases are posted to https://nodejs.org/download/rc/, so it would make the logic more complicated in
setup-nodeto merge the two together and that could introduce some unexpected problems. That would be a reason to avoidallow-prereleasesat the moment.allow-alphaseems to be the safest way to implement this functionality at the moment. Perhaps in the future an additionalallow-prereleasescould be considered as a further enhancement after gaining some experience during the Node.js 27 Alpha, RC, Current and LTS phases?The Node.js 27 Alpha phase lasts 6 months, so I would expect this option to be widely used, especially for package maintainers who want to do ongoing CI testing against each Node.js 27 Alpha release which comes out with a 2 week cadence.
So, my choice right now would be to implement
allow-alpha.[-]Provide `allow-prereleases` option for Node.js 27 Alpha[/-][+]Provide `allow-prereleases` (or similar) option for Node.js 27 Alpha[/+]v-priyagupta108 commentedon Nov 11, 2026
Thanks @MikeMcC399, that's really helpful, and we agree.
We'll go ahead with
allow-alpha. Since alphas are released regularly over a long phase, pinning exact versions quickly becomes impractical. The RC phase is much shorter with only a few releases, so exact RC versions should work well for now, and we'll look at range support for RCs separately based on feedback.We'll link the PR here once it's ready.