build: add expected assets for v27.x

[RafaelGSS]

build: add expected assets for v27.x

Based on v26.x, without the darwin-x64 tarballs that are no longer
built from v27.x (see #4470 and nodejs/node#65427). Also test that
Alpha versions, e.g. v27.0.0-alpha.0.0.0, are checked against the
expected assets of their release line.

Refs: https://github.com/nodejs/Release/issues/1187

The first Alpha, v27.0.0-alpha.0.0.0, is planned for 2026-10-28. With
this change, Alpha releases are promoted to /download/release like any
other release. Should they go to a separate /download/alpha instead?
That would keep them out of /download/release/index.json, which tools
like nvm and setup-node use to resolve the latest version.

PTAL @nodejs/build

[richardlau]

The first Alpha, v27.0.0-alpha.0.0.0, is planned for 2026-10-28. With this change, Alpha releases are promoted to /download/release like any other release. Should they go to a separate /download/alpha instead? That would keep them out of /download/release/index.json, which tools like nvm and setup-node use to resolve the latest version.

This decision needs to be made, and I'm not sure this should be wholly Build's decision as it will affect how or if e.g. nvm can pick up the alpha releases at all. If we do decide to put them into a separate directory, that can be done but it'll be more work to make it happen.

[MikeMcC399]

Should they go to a separate /download/alpha instead?
That would keep them out of /download/release/index.json, which tools like nvm and setup-node use to resolve the latest version.

If Node.js 27 Alpha releases are promoted to a separate location, I suspect that they will hardly get used.

It will also introduce additional issues and risks for Cloudflare promotion and indexing. The nightly index problem nodejs/release-cloudflare-worker#1034 as an example of an alternate location is still unsolved.

Downstream Node.js version manager consumers: actions/setup-node, nvm, n, nvm-windows, brew, chocolatey, fnm, etc. would either adapt, or more likely, they would ignore an alternate location. nvm for instance has yet to implement nightly downloads as an alternate source.

The downstream Docker builder docker-node needs to make changes in any case, since it can't deal with pre-releases, wherever they are located. nodejs/docker-node#2524 is tracking preparation. If Node.js 27 Alpha releases are located elsewhere, it would make it more complex to deal with and could delay the adoption.

I checked cypress-io/cypress-docker-images and it does not look like it would need any changes to build based on Node.js 27 Alpha, however that only holds true if the promotion location says the same as regular releases.

It remains to be seen whether other Docker builders like CircleCI-Public/cimg-node will adopt Alpha releases. They may decide not to, and in that case the location won't be important.

I suggest to keep the same base location for Alpha releases. If a different location is chosen, there would have to be good reasons for doing this, and the impact would need to be understood fully.

[richardlau]

Just for clarity, alphas will go into the existing release directory unless changes are made (hence my "more work" comment if we want to put them into a different directory, which it is not clear that we do).

[nschonni]

I think "dist" used to have an "RC" folder like https://unofficial-builds.nodejs.org/download/rc/, but I'm not sure that why away with the R2 stuff

[MikeMcC399]

I think "dist" used to have an "RC" folder like https://unofficial-builds.nodejs.org/download/rc/, but I'm not sure that why away with the R2 stuff

There is still a directory https://nodejs.org/download/rc/, last used for https://nodejs.org/download/rc/v26.4.0-rc.0/ 23-June-2026.