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?
NPM package security is a far bigger problem than some ephemeral invocation that probably isn't under PCI-DSS or HIPAA and doesn't serve content to the wild interwebs. Amount of caring should be nuanced for the use-case rather than projecting blanket, absolutist declarations.
I believe the guidance holds true regardless: only maintained code should run in these execution contexts. Otherwise, you are assuming more risk (needlessly, imho). How much more risk? I cannot say. Everyone’s risk appetite is different, but hosted providers clearly have an incentive to reduce their risk, as do most businesses.
If you want to run builds with old containers running old code on your personal equipment, sure, that’s fine, the impact is likely limited to you. A person has little financial, liability, or reputational risk.
Why is Github enforcing that decision rather than leaving it to the developer to enforce it as part of their workflow? At the bare minimum, why not give the developer the option to override the decision? Something on the lines of "Do you really want to run node 20?"
The article shows that such an option does exist. But it will be phased out in 3 stages, making it impossible to run node 20 eventually. This really does disrupt the standard software development practice of reproducible builds. Safety determinations must be implemented orthogonally to reproducible builds.
Ultimately, this is the next stage in the war on computing freedom and general purpose computing. They're moving from "We decide what you're allowed to run." to "We decide what you're allowed to develop." I know that many will object to this calling it an overreaction and claim that nobody is forced to use their CI/CD system. But as history has shown time and again, lock-in and restrictions come in numerous small doses that are individually too small to trigger the alarm bells among the general population.
> If you want full control, install and use your own runners, which flips the responsibility to you.
It's a bit tedious to have to explain that service providers have certain responsibilities and obligations too. Corporate culture has given bigtech a blank cheque to behave the way they want. That aside, based on the way you framed your reply, let me assure you that I don't trust them with even my projects, much less the CI system or their runner. And time and again, they vindicate that decision. I have posted the full argument as a reply to your sibling comment.
I'm still paying for these github runners. There is also some line between fully dictating which versions of languages and packages you are allowed to use and a managed runner that doesn't get in your way like a control freak.
because your "yes" might mean you are putting other projects at risk depending on the vulnerability.
Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.
go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.
You can absolutely install Node 20 yourself on GitHub's runners if you want and GitHub is fine with that. GitHub itself, and other projects, are protected by isolation from your workloads. Their security does not depend on the software you're running in your workflow. TFA is just talking about the version that comes preinstalled and is used by JavaScript-based actions.
> because your "yes" might mean you are putting other projects at risk depending on the vulnerability.
By ruining build reproducibility through such short sighted decisions, you are actually compromising a security measure. And I already proposed a way to overcome this problem if you insist on disabling node 20 by default - provide a way to explicitly override it when needed.
Besides, the security model you suggest isn't even the correct way to deal with supply chain vulnerabilities. They have to be version-flagged at the artifact distribution point, not at the CI stage by unilaterally imposing backwards-incompatible restrictions.
> Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.
There are two fundamental issues with that argument here. Any user depends on services like these after entering an agreement with a service provider (Github). Even free tier users agree to the ToS. This is significant because the developer(s) are making an investment on the provider's service. GAs are not seamlessly transferrable to any competing service, even ones that try to replicate GA. The users are basically soft locking themselves in to the platform. It takes nontrivial effort from the user if they want to migrate away. In such situations, it's only ethically and morally correct for the service provider to never blindly pull the rug from under the users like this. This is especially true with paying customers.
The second problem with that argument is that it's not fair for the service provider to keep shifting the goal post once the restrictions have been agreed upon by both parties. In case of GA, the developers are not doing whatever they please on Github's servers. Their actions are executed within a restricted context with predefined restrictions. Any damage is restricted to that context and is ephemeral. Arbitrary modification of those restrictions later on only creates headache for the developers without any meaningful benefits.
> go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.
I stay away from GH as much as possible precisely because this uncaring attitude of theirs. As I explained earlier, it's not trivial to migrate even to GA lookalikes. I would rather target a different platform that wouldn't randomly rugpull from under me like this.
You're spreading FUD, assuming unprofessionalism, and making a strawman argument based on nebulous hypotheticals and assuming the worst intention and stupidity. There are plenty of vendors who $upport "unsupported" versions of many languages, libraries, and frameworks with backported security and functionality patches for things that matter that are too expensive to update and are outside of FOSS support. For other things that don't matter, sometimes prototyping or one-of runs the functionality of executing is far more important than any or all CVEs that aren't exposed in any material manner. This is the definition of nuance.
I am sharing my professional opinion based on real world experience and subject matter expertise, so others can take what is of value and disregard what is not. You are free to disregard it in its entirety if you wish.
My day job org is a Github customer with a few hundred thousand dollars of annual spend with them, so while we get their ear, we don't move the needle with regards to product changes (their customer success team is very helpful when they can be though). I imagine the situation is not as great if you are a free user, or someone with immaterial spend with them; you're simply along for the ride.
As always, do what is best for your risk and threat model.
I look at it as “The risk of running unmaintained code on an old interpreter version is difficult to quantify and therefore it is low cost and effort to require it run on a maintained, recent version.” Developers will argue their time is too valuable to require such code be updated to run on recent interpreter versions, and I’ll argue it’s cheaper than chasing successful exploits and any footholds established. Dev Vs Ops, a tale as old as time.
Perhaps having had to run down potential exposure across a large enterprise from the recent npm supply chain attack has made me a bit more paranoid lately around supply chain and cicd security. But, I get paid to be paranoid, so it is what it is. Run your own runners I suppose? Hard to complain when someone else is running the infrastructure for you (and you’re not paying enterprise prices). Supply chain and hosted/multi tenant execution code security is just fundamentally hard and fraught with peril. Ongoing deprecations to keep up with current state are therefore unavoidable.
I think GitHub Actions is missing a distinction between builds and automation.
When I build my software I care less about eliminating security vulnerabilities (after all, I need to build while updating to fix security issues), but also don't need, or ideally don't want any external access. A vulnerability in the build toolchain should be encoded into the artifacts but shouldn't necessarily prevent artifacts being generated.
However when I automate processes, like categorising bugs etc, I care a lot about eliminating security vulnerabilities because there is necessary external access, often write access, to my sensitive data.
GitHub considers these two things the same, but they're distinct use-cases with distinct approaches to maintenance, updating, and security.
Why both the pipe into sh and eval? The latter could handle all everything.
Couple more thoughts and unsolicited feedback from a quick eyeball:
- Use https://
- Wrap everything in a shell function to ensure that partial content is not executed.
- Wrap variable substitutions with "${OUTPUT_DIR}" to prevent arg splitting if they contain whitespace. Line 124, `rm -rf $OUT_DIR_INSTALL` is pretty scary if invoked with whitespace in OUT_DIR.
- Download nodejs tarball to temp directory and then extract them to prevent partial extraction
> 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.)
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.
> Why would I care whether the Node runner has a security vulnerability?
Because that "build" process has free access to your repo and potentially your organization. If your repo is also where you deploy from, then potentially deploying a vulnerable version of your software, live to your users.
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.
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.
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.
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 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).
> 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.
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.
> 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.
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.
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.
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.
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?
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.
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?
> GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?
"Why do I care if there is a potentially insecure code interpreter in my arbitrary code execution service?"
As someone where appsec is a component of my work in financial services, please believe you should care.
NPM package security is a far bigger problem than some ephemeral invocation that probably isn't under PCI-DSS or HIPAA and doesn't serve content to the wild interwebs. Amount of caring should be nuanced for the use-case rather than projecting blanket, absolutist declarations.
I believe the guidance holds true regardless: only maintained code should run in these execution contexts. Otherwise, you are assuming more risk (needlessly, imho). How much more risk? I cannot say. Everyone’s risk appetite is different, but hosted providers clearly have an incentive to reduce their risk, as do most businesses.
If you want to run builds with old containers running old code on your personal equipment, sure, that’s fine, the impact is likely limited to you. A person has little financial, liability, or reputational risk.
Why is Github enforcing that decision rather than leaving it to the developer to enforce it as part of their workflow? At the bare minimum, why not give the developer the option to override the decision? Something on the lines of "Do you really want to run node 20?"
The article shows that such an option does exist. But it will be phased out in 3 stages, making it impossible to run node 20 eventually. This really does disrupt the standard software development practice of reproducible builds. Safety determinations must be implemented orthogonally to reproducible builds.
Ultimately, this is the next stage in the war on computing freedom and general purpose computing. They're moving from "We decide what you're allowed to run." to "We decide what you're allowed to develop." I know that many will object to this calling it an overreaction and claim that nobody is forced to use their CI/CD system. But as history has shown time and again, lock-in and restrictions come in numerous small doses that are individually too small to trigger the alarm bells among the general population.
> Why is Github enforcing that decision..
Because at the end of the day, Github is responsible for _their_ runners.
If you want full control, install and use your own runners, which flips the responsibility to you.
> If you want full control, install and use your own runners, which flips the responsibility to you.
It's a bit tedious to have to explain that service providers have certain responsibilities and obligations too. Corporate culture has given bigtech a blank cheque to behave the way they want. That aside, based on the way you framed your reply, let me assure you that I don't trust them with even my projects, much less the CI system or their runner. And time and again, they vindicate that decision. I have posted the full argument as a reply to your sibling comment.
I'm still paying for these github runners. There is also some line between fully dictating which versions of languages and packages you are allowed to use and a managed runner that doesn't get in your way like a control freak.
because your "yes" might mean you are putting other projects at risk depending on the vulnerability. Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.
go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.
But it's a CI system! It is literally running code you provide. You could put Node 20 in there if you wanted anyway.
You can absolutely install Node 20 yourself on GitHub's runners if you want and GitHub is fine with that. GitHub itself, and other projects, are protected by isolation from your workloads. Their security does not depend on the software you're running in your workflow. TFA is just talking about the version that comes preinstalled and is used by JavaScript-based actions.
> because your "yes" might mean you are putting other projects at risk depending on the vulnerability.
By ruining build reproducibility through such short sighted decisions, you are actually compromising a security measure. And I already proposed a way to overcome this problem if you insist on disabling node 20 by default - provide a way to explicitly override it when needed.
Besides, the security model you suggest isn't even the correct way to deal with supply chain vulnerabilities. They have to be version-flagged at the artifact distribution point, not at the CI stage by unilaterally imposing backwards-incompatible restrictions.
> Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.
There are two fundamental issues with that argument here. Any user depends on services like these after entering an agreement with a service provider (Github). Even free tier users agree to the ToS. This is significant because the developer(s) are making an investment on the provider's service. GAs are not seamlessly transferrable to any competing service, even ones that try to replicate GA. The users are basically soft locking themselves in to the platform. It takes nontrivial effort from the user if they want to migrate away. In such situations, it's only ethically and morally correct for the service provider to never blindly pull the rug from under the users like this. This is especially true with paying customers.
The second problem with that argument is that it's not fair for the service provider to keep shifting the goal post once the restrictions have been agreed upon by both parties. In case of GA, the developers are not doing whatever they please on Github's servers. Their actions are executed within a restricted context with predefined restrictions. Any damage is restricted to that context and is ephemeral. Arbitrary modification of those restrictions later on only creates headache for the developers without any meaningful benefits.
> go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.
I stay away from GH as much as possible precisely because this uncaring attitude of theirs. As I explained earlier, it's not trivial to migrate even to GA lookalikes. I would rather target a different platform that wouldn't randomly rugpull from under me like this.
You're spreading FUD, assuming unprofessionalism, and making a strawman argument based on nebulous hypotheticals and assuming the worst intention and stupidity. There are plenty of vendors who $upport "unsupported" versions of many languages, libraries, and frameworks with backported security and functionality patches for things that matter that are too expensive to update and are outside of FOSS support. For other things that don't matter, sometimes prototyping or one-of runs the functionality of executing is far more important than any or all CVEs that aren't exposed in any material manner. This is the definition of nuance.
I am sharing my professional opinion based on real world experience and subject matter expertise, so others can take what is of value and disregard what is not. You are free to disregard it in its entirety if you wish.
My day job org is a Github customer with a few hundred thousand dollars of annual spend with them, so while we get their ear, we don't move the needle with regards to product changes (their customer success team is very helpful when they can be though). I imagine the situation is not as great if you are a free user, or someone with immaterial spend with them; you're simply along for the ride.
As always, do what is best for your risk and threat model.
I mean he's been running version 20 for years already, what's changed to make it now suddenly insecure?
Everything is insecure, the question is has anyone found the vulnerability in it yet
I look at it as “The risk of running unmaintained code on an old interpreter version is difficult to quantify and therefore it is low cost and effort to require it run on a maintained, recent version.” Developers will argue their time is too valuable to require such code be updated to run on recent interpreter versions, and I’ll argue it’s cheaper than chasing successful exploits and any footholds established. Dev Vs Ops, a tale as old as time.
Perhaps having had to run down potential exposure across a large enterprise from the recent npm supply chain attack has made me a bit more paranoid lately around supply chain and cicd security. But, I get paid to be paranoid, so it is what it is. Run your own runners I suppose? Hard to complain when someone else is running the infrastructure for you (and you’re not paying enterprise prices). Supply chain and hosted/multi tenant execution code security is just fundamentally hard and fraught with peril. Ongoing deprecations to keep up with current state are therefore unavoidable.
I think GitHub Actions is missing a distinction between builds and automation.
When I build my software I care less about eliminating security vulnerabilities (after all, I need to build while updating to fix security issues), but also don't need, or ideally don't want any external access. A vulnerability in the build toolchain should be encoded into the artifacts but shouldn't necessarily prevent artifacts being generated.
However when I automate processes, like categorising bugs etc, I care a lot about eliminating security vulnerabilities because there is necessary external access, often write access, to my sensitive data.
GitHub considers these two things the same, but they're distinct use-cases with distinct approaches to maintenance, updating, and security.
Surely 101 of "come back to a project and it still works unchanged" is "dont use proprietary hosted services"?
As well as "don't use anything JS related"
It works as long as one keeps to vanillaJS, it is a great framework.
Then don't use the GitHub Actions defaults? Write your own Nodejs install script and use that instead.
That's what I do and it's pretty stable: https://github.com/alshdavid-templates/siteforge/blob/main/....
Why both the pipe into sh and eval? The latter could handle all everything.
Couple more thoughts and unsolicited feedback from a quick eyeball:
- Use https://
- Wrap everything in a shell function to ensure that partial content is not executed.
- Wrap variable substitutions with "${OUTPUT_DIR}" to prevent arg splitting if they contain whitespace. Line 124, `rm -rf $OUT_DIR_INSTALL` is pretty scary if invoked with whitespace in OUT_DIR.
- Download nodejs tarball to temp directory and then extract them to prevent partial extraction
Stuff rots even when you self-host just because of OS updates.
> 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.)
Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)
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.
literally code execution as a service
As in, kills your old build code dead?
You can host the GitHub actions runner yourself and decide which node versions you want to keep around
Are you serious? Is updating dependencies and runners controversial somehow?
Just update your dependencies, it's not that hard. And it's even easier when you do it routinely as part of a deprecation planning.
> Why would I care whether the Node runner has a security vulnerability?
Because that "build" process has free access to your repo and potentially your organization. If your repo is also where you deploy from, then potentially deploying a vulnerable version of your software, live to your users.
you use their shared runner, that's what you should expect.
That's why we should have all the dependencies for the project in our own repo!
Then don't use Docker. You never know the image you are using will be outdated.
... then your infrastructure deployment keys leak as a result.
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.
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.
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.
And this is particularly painful, if you actually need to run, build, and test on old OS versions, that come with old Node versions.
Just want to plug 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 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).
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.
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.
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.
> 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...
Brilliant. I think very few people care about older OSes and this is magical to see.
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.
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.
Same for Vercel which doesn’t support 24 officially yet.
https://vercel.com/docs/functions/runtimes/node-js/node-js-v...
Is there a specific part of Node 22 that isn’t there in Node 24?
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.
What are you doing that requires checking in the compiled version. Esbuild takes like one second
The code is written in typescript. So we go from
toYou 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
I think it just ignores types, so may not suit all use cases.
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-typ...
It's safe to use the LTS, which you can track here: https://endoflife.date/nodejs
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.
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.