6 ms·

Node 20 will be deprecated on GitHub Actions runners

109 points by redbell 1y ago

esafak 1y ago
It's safe to use the LTS, which you can track here: https://endoflife.date/nodejs https://endoflife.date/nodejs
stackskipton 1y ago
Ops type here, something important to understand is Node is language the runner client uses so in particular, this is impactful for anyone building self-hosted runners and a will be a problem for anyone still writing Node 20 applications that just use self-hosted runner Node.
- fisf 1y ago
  And this is particularly painful, if you actually need to run, build, and test on old OS versions, that come with old Node versions.
OptionOfT 1y ago
Very sad they went from 20 to 24. No 22. OTOH I've been moving from native NodeJS actions to packing them in a Docker container to separate code from compiled code. If you wanted to use Typescript for your action you always had a 2 step process because GitHub Actions required you to pack dependencies with ncc or vite or webpack. This packaged version was subsequently committed to the main branch. Technically I could do a composite action where I compile the typescript on the fly, but that was fragile last time I tried it.
- STRiDEX 1y ago
  What are you doing that requires checking in the compiled version. Esbuild takes like one second
  - OptionOfT 1y ago
    The code is written in typescript. So we go from * cloning the action * running the dist/index.js to * Cloning the action * npm install * npm compile * npm run
    - franky47 1y ago
      You can run TypeScript natively in Node.js 24, actions based on that runtime don’t need a build step. https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x
      - matt-p 1y ago
        I think it just ignores types, so may not suit all use cases.
        franky47 1y ago
        It has a (albeit experimental) flag for transforming enums, namespaces and other runtime-impacting aspects of TypeScript, if that’s what you were referring to? https://nodejs.org/api/cli.html#--experimental-transform-types https://nodejs.org/api/cli.html#--experimental-transform-typ...
- romellem 1y ago
  Is there a specific part of Node 22 that isn’t there in Node 24?
- chrisweekly 1y ago
  Yeah, strange to skip 22. If GHA is mandating 24, while other vendors like Netlify currently max out at 22, there isn't even overlap in an LTS version I can deploy to both places? Just, wat.
  - vinnymac 1y ago
    Same for Vercel which doesn’t support 24 officially yet. https://vercel.com/docs/functions/runtimes/node-js/node-js-versions https://vercel.com/docs/functions/runtimes/node-js/node-js-v...
- mirekrusin 1y ago
  Sadly docker actions can't be used in workflows that run on custom image (docker is not available in docker and making it available is an anti pattern) - they loose on their composability.
bramblerose 1y ago
I find the repeated deprecations on GitHub Actions frustrating to work with. One of the key goals of a build system is to be able to come back to a project after several years and just having the build work out of the box. Yet with GHA I need to update actions/checkout@v2 to actions/checkout@vwhatever (or, what I'm doing now, actions/checkout@main because the actual API haven't actually changed) because... some Node version is "out of maintenance"?! GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?
- turboponyy 1y ago
  If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.
- easton 1y ago
  > Why would I care whether the Node runner has a security vulnerability? I’m guessing they know you don’t care, but the big company customers cant have a CVE anywhere and won’t accept a EOL node version so they can check a box on something. (I guess there’s also people with self hosted runners, who might be running them inside networks that aren’t segmented.)
  - Wowfunhappy 1y ago
    Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)
- tracker1 1y ago
  ... then your infrastructure deployment keys leak as a result.
  - niffydroid 1y ago
    I don't expect to come back after x years and a build system to work. You're very much at the mercy of multiple components in your stack and environment. For example you could be on a Mac and 2 years ago you were using x64, but now you are on ARM64. Whole load of stuff just breaks from that alone.
Wowfunhappy 1y ago
> Node24 is incompatible with macOS 13.4 and lower versions. ...wait, really? I have NodeJS 24 working all the way back on macOS 10.9 [1]. I realize official support is a very different thing, but I'm still surprised they can't do better than Ventura. 1: https://github.com/Wowfunhappy/Node-24-Mavericks/blob/master/build-nodejs-mavericks.sh https://github.com/Wowfunhappy/Node-24-Mavericks/blob/master...
- vintagedave 1y ago
  Brilliant. I think very few people care about older OSes and this is magical to see.
sethops1 1y ago
Just want to plug https://github.com/ChristopherHX/github-act-runner https://github.com/ChristopherHX/github-act-runner (not mine) It's re-implementation of the GHA self-hosted runner in Go for self-hosted runners, based on the popular https://github.com/nektos/act https://github.com/nektos/act for running GHA locally. Been using this for over a year now and it's been infinitely useful for CI on otherwise unsupported systems (e.g. freeBSD, openBSD in my case).
- hamandcheese 1y ago
  From the readme: > Local Task Runner - I love make. However, I also hate repeating myself. With act, you can use the GitHub Actions defined in your .github/workflows/ to replace your Makefile! This is ass backwards. Throwing out a tried and true build system in favor of a vendor-specific yaml format? Wtf? Just invoke make from your actions ffs.
  - wiether 1y ago
    I 100% get the purpose of the `act` tool, but I don't get why they wrote this sentence around `make`. The tool is here to run GHA tasks locally, period. It's not a replacement for a Makefile. And I agree with you: use `make` in your actions! If I want to make sense of the sentence, the only thing I can think of is that, before making this tool, they were using a Makefile locally to replicate the content of their GHA tasks.
    - figmert 1y ago
      Just be careful with Make's exit codes. Just gobbles them up and exits 2 with no way of disabling it from what I could gather. Instead use mise tasks.
deleted 1y ago
[deleted]
matt-p 1y ago
Node 20 was the latest version, also with LTS support 2 years ago. The main problem was it was actually really hard to use at that point as many dependencies weren't compatible with it, so you have to wait until those dependencies are updated to node 20 before you can use it in your project and by the time that's done maybe you've got a year of support left before you need to upgrade the project. So essentially this is a yearly dance. There's many projects in the real world where they're not touched by a developer in a given year. That doesn't mean they're broken or stale, the opposite, it means they're such great tools that they don't need changing. It's a bit of an annoying hassle that frankly is not an issue in many other languages.
elAhmo 1y ago
Using LTS for Node releases is quite lauhable, given how long it takes for ecosystem to catch up, just before providers move to maintenance mode.
zipy124 1y ago
One annoying thing is you'd expect a company the size of microsoft to have an agreement for extended support. For example ubuntu 20.04 is no longer available as a runner on github actions as support ended in May of 2025, but extended support is available for a price until 2030. You'd think for a paid service they could pony up for a few licenses to keep things running, or provide an option for you to provide your own license.

109 points by redbell 1y ago

It's safe to use the LTS, which you can track here: https://endoflife.date/nodejs https://endoflife.date/nodejs

Ops type here, something important to understand is Node is language the runner client uses so in particular, this is impactful for anyone building self-hosted runners and a will be a problem for anyone still writing Node 20 applications that just use self-hosted runner Node.

fisf 1y ago
And this is particularly painful, if you actually need to run, build, and test on old OS versions, that come with old Node versions.

OptionOfT 1y ago

Very sad they went from 20 to 24. No 22. OTOH I've been moving from native NodeJS actions to packing them in a Docker container to separate code from compiled code. If you wanted to use Typescript for your action you always had a 2 step process because GitHub Actions required you to pack dependencies with ncc or vite or webpack. This packaged version was subsequently committed to the main branch. Technically I could do a composite action where I compile the typescript on the fly, but that was fragile last time I tried it.

STRiDEX 1y ago
What are you doing that requires checking in the compiled version. Esbuild takes like one second
- OptionOfT 1y ago
  The code is written in typescript. So we go from * cloning the action * running the dist/index.js to * Cloning the action * npm install * npm compile * npm run
  - franky47 1y ago
    You can run TypeScript natively in Node.js 24, actions based on that runtime don’t need a build step. https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x
    - matt-p 1y ago
      I think it just ignores types, so may not suit all use cases.
      - franky47 1y ago
        It has a (albeit experimental) flag for transforming enums, namespaces and other runtime-impacting aspects of TypeScript, if that’s what you were referring to? https://nodejs.org/api/cli.html#--experimental-transform-types https://nodejs.org/api/cli.html#--experimental-transform-typ...
romellem 1y ago
Is there a specific part of Node 22 that isn’t there in Node 24?
chrisweekly 1y ago
Yeah, strange to skip 22. If GHA is mandating 24, while other vendors like Netlify currently max out at 22, there isn't even overlap in an LTS version I can deploy to both places? Just, wat.
- vinnymac 1y ago
  Same for Vercel which doesn’t support 24 officially yet. https://vercel.com/docs/functions/runtimes/node-js/node-js-versions https://vercel.com/docs/functions/runtimes/node-js/node-js-v...
mirekrusin 1y ago
Sadly docker actions can't be used in workflows that run on custom image (docker is not available in docker and making it available is an anti pattern) - they loose on their composability.

bramblerose 1y ago

I find the repeated deprecations on GitHub Actions frustrating to work with. One of the key goals of a build system is to be able to come back to a project after several years and just having the build work out of the box. Yet with GHA I need to update actions/checkout@v2 to actions/checkout@vwhatever (or, what I'm doing now, actions/checkout@main because the actual API haven't actually changed) because... some Node version is "out of maintenance"?! GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?

turboponyy 1y ago
If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.
easton 1y ago
> Why would I care whether the Node runner has a security vulnerability? I’m guessing they know you don’t care, but the big company customers cant have a CVE anywhere and won’t accept a EOL node version so they can check a box on something. (I guess there’s also people with self hosted runners, who might be running them inside networks that aren’t segmented.)
- Wowfunhappy 1y ago
  Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)
tracker1 1y ago
... then your infrastructure deployment keys leak as a result.
- niffydroid 1y ago
  I don't expect to come back after x years and a build system to work. You're very much at the mercy of multiple components in your stack and environment. For example you could be on a Mac and 2 years ago you were using x64, but now you are on ARM64. Whole load of stuff just breaks from that alone.

Wowfunhappy 1y ago

> Node24 is incompatible with macOS 13.4 and lower versions. ...wait, really? I have NodeJS 24 working all the way back on macOS 10.9 [1]. I realize official support is a very different thing, but I'm still surprised they can't do better than Ventura. 1: https://github.com/Wowfunhappy/Node-24-Mavericks/blob/master/build-nodejs-mavericks.sh https://github.com/Wowfunhappy/Node-24-Mavericks/blob/master...

vintagedave 1y ago
Brilliant. I think very few people care about older OSes and this is magical to see.

sethops1 1y ago

Just want to plug https://github.com/ChristopherHX/github-act-runner https://github.com/ChristopherHX/github-act-runner (not mine) It's re-implementation of the GHA self-hosted runner in Go for self-hosted runners, based on the popular https://github.com/nektos/act https://github.com/nektos/act for running GHA locally. Been using this for over a year now and it's been infinitely useful for CI on otherwise unsupported systems (e.g. freeBSD, openBSD in my case).

hamandcheese 1y ago
From the readme: > Local Task Runner - I love make. However, I also hate repeating myself. With act, you can use the GitHub Actions defined in your .github/workflows/ to replace your Makefile! This is ass backwards. Throwing out a tried and true build system in favor of a vendor-specific yaml format? Wtf? Just invoke make from your actions ffs.
- wiether 1y ago
  I 100% get the purpose of the `act` tool, but I don't get why they wrote this sentence around `make`. The tool is here to run GHA tasks locally, period. It's not a replacement for a Makefile. And I agree with you: use `make` in your actions! If I want to make sense of the sentence, the only thing I can think of is that, before making this tool, they were using a Makefile locally to replicate the content of their GHA tasks.
  - figmert 1y ago
    Just be careful with Make's exit codes. Just gobbles them up and exits 2 with no way of disabling it from what I could gather. Instead use mise tasks.

deleted 1y ago

[deleted]

matt-p 1y ago

Node 20 was the latest version, also with LTS support 2 years ago. The main problem was it was actually really hard to use at that point as many dependencies weren't compatible with it, so you have to wait until those dependencies are updated to node 20 before you can use it in your project and by the time that's done maybe you've got a year of support left before you need to upgrade the project. So essentially this is a yearly dance. There's many projects in the real world where they're not touched by a developer in a given year. That doesn't mean they're broken or stale, the opposite, it means they're such great tools that they don't need changing. It's a bit of an annoying hassle that frankly is not an issue in many other languages.

elAhmo 1y ago

Using LTS for Node releases is quite lauhable, given how long it takes for ecosystem to catch up, just before providers move to maintenance mode.

zipy124 1y ago

One annoying thing is you'd expect a company the size of microsoft to have an agreement for extended support. For example ubuntu 20.04 is no longer available as a runner on github actions as support ended in May of 2025, but extended support is available for a price until 2030. You'd think for a paid service they could pony up for a few licenses to keep things running, or provide an option for you to provide your own license.