You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide allow-prereleases option for Node.js 27 Alpha #1657
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):
Edit: according to the discussion in #1660latest will be changed to install the latest non-alpha version, so the following will not be a future workaround:
Run actions/setup-node@v7Attempting to download 27.0.0-alpha.0.0.0...Not found in manifest. Falling back to download directly from NodeAcquiring 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.gzExtracting .../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-a2b3900392cfAdding to the cache ...DoneEnvironment details node: v27.0.0-alpha.0.0.0 npm: 12.1.0 yarn: 1.22.22
I just realized that node-version: latest picks up 27.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 latest by Node.js version managers, and the definition used by Node.js itself, so I've raised that in nodejs/node#67135.
After looking into this, we're leaning towards a new allow-alpha input (default false) rather than allow-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 named allow-prereleases would suggest those channels are included as well, so allow-alpha describes exactly what it does.
It would behave similarly to allow-prereleases in 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.0 will 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.
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.