chore: run CI on latest Node.js

[ehmicky]

Part of https://github.com/netlify/team-dev/issues/19

This runs the CI on the latest Node.js version.

[eduardoboucas]

We should probably update https://github.com/netlify/zip-it-and-ship-it/blob/main/.github/workflows/benchmark.yml#L19 too. There's also https://github.com/netlify/zip-it-and-ship-it/blob/main/.github/workflows/release-please.yml#L25, but I wonder if we want to update that one too?

[ehmicky]

Good point, I missed those. Fixed!
Changing all of them would make sense with the goal of not having to update them in the future.

[github-actions]

⏱ Benchmark results

Comparing with f188133

• largeDepsEsbuild: 10.3s ⬇️ (14.12% decrease)
• largeDepsZisi: 53.6s ⬇️ (15.52% decrease)

[eduardoboucas]

What happens if we don't use check-latest here? From https://github.com/actions/setup-node:

When set to false, the action tries to first resolve a version of node from the local cache. (...) The local version of Node in cache gets updated every couple of weeks. If unable to find a specific version in the cache, the action will then attempt to download a version of Node.

And:

Setting check-latest to true has performance implications as downloading versions of Node is slower than using cached versions

I wonder about these performance implications as we try to speed up the CI runs. If we use * without check-latest, does it mean we may only get an updated version after GitHub updates the image? If so, how do we feel about this trade-off?

[erezrokah]

Looks like download time is a few seconds
Linux is 4s, MacOS is 5s and Windows is 9s (based on this run).
This is a single sample, but I don't expect it to be much higher.

I've also subscribed to actions/setup-node#26 so we might be able to use lts in the future

[eduardoboucas]

Cool, in case that this looks good to me! 🚀

[ehmicky]

I added check-latest: true because without it, * is tried against the cached Node.js versions which seemed to be 10, 12 and 14. So without it, * was somehow resolving to 14.*.*. :-/

I have experimented with several other ranges, and none worked: latest, current, *.*.*. I dug into the code of actions/setup-node doing the logic and it seems like this is mostly based on running semver.satisfies(), i.e. it expects semver ranges, not tags. The only one which did work was to use something like >1 but I was not 100% sure whether this would always behave correctly.

[ehmicky]

Note: there is also this ongoing PR which is actually adding a library of mine to actions/setup-node and would allow using latest without needing check-latest: true.