10 ms·

Bringing Forward the End-of-Life Date for Node.js 16

102 points by WalterSobchak 4y ago

sparrish 4y ago
A bad situation with no good solution. I guess moving the EOL was the least sucky thing to do.
- sanjayio 4y ago
  To be fair, upgrading Node hasn’t historically been tough.
  - forty 4y ago
    I agree for recent history at least. With that said, recent releases also haven't brought life changing changes either, so the incentive to upgrade remain low even if it's mostly painless.
  - solardev 4y ago
    M1 added a lot of headaches to that... some older libs don't support newer Nodes running in native Apple Silicon mode :( Upgrading from 16 to 18 on Windows or Linux took me like 2 minutes of resolving some conflicts. That same repo took several days of investigation on M1, and eventually I gave up...
bcjordan 4y ago
AWS Lambda[0] and GCP Functions[1] both say they support only up to Node 16 today. Hopefully they'll get new versions shipped with enough lead time for customers to upgrade ahead of the deprecation. (There are things like Cloud Run to bring your own container that could be used sooner) [0]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.h... [1]: https://cloud.google.com/functions/docs/concepts/nodejs-runtime https://cloud.google.com/functions/docs/concepts/nodejs-runt...
- iends 4y ago
  This is largely because Node 16 is the current LTS.
  - FBISurveillance 4y ago
    Node 16 graduated to LTS on 20 Apr 2021. Lambda added support for Node 16 just last month, basically 13 months after. I hope they add Node 18 sooner than that.
    - akmittal 4y ago
      Node 18 will be active LTS in October this year. So they will have 11 month of buffer
    - rantallion 4y ago
      AWS have already openly admitted that they were slow bringing Node 16 support and plan to be quicker next time round. > We recognize that customers have been waiting for some time for this runtime release. We hear your feedback and plan to release the next Node.js runtime version in a timelier manner. https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-now-available-in-aws-lambda/ https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-no...
- mhoad 4y ago
  I don’t know the AWS ecosystem but in the meantime on GCP at least just use Cloud Run rather than Cloud Functions and keep whatever run time you want and pick up a bunch of other benefits in the process. Their latest version of Cloud Functions is actually using Cloud Run under the hood already.
  - explaingarlic 4y ago
    Cloud Run introduces a heap of other considerations at the enterprise level - container building and repository management which may not be managed by your team etc. Cloud Functions/Lambda are very nice in a company where you don't necessarily have access to making your own AMI, or container image etc. At least that's what we used them for at my old job. Still had to deal with some level of corporate tech indirection (E.G. We couldn't make the API gateway however we wanted, our account had no access to route53 etc.), but much less than with containers. It was just a quicker way to get code running.
jtwebman 4y ago
I feel they should make Node.js 18 lts sooner than when they do these. That way people have time to switch if they only use lts.
- leipert 4y ago
  NodeJS becomes LTS in October. That leaves people 11 months to switch. It is out right now albeit not LTS, so you can prep the switch and switch as soon as it becomes LTS. If they’d move to LTS a month earlier, not a whole lot of people would gain something from it.
  - forty 4y ago
    Some people like using Maintenance LTS, which only gets security and bug fixes (as opposed to Active LTS which can also get backported features)
barelysapient 4y ago
Great communication from the team. Here’s our choices. Here’s our thinking. Here’s what we decided and why. Not ideal but it’s still over a year from now which gives folks time to plan.
lightswitch05 4y ago
It seems like the most reasonable choice. Incidentally, I have an open-source tool called Node Version Audit [0] which checks a given node version against known CVEs and end-of-life dates. It looks like the official change hasn’t been made yet [1]. [0] https://www.github.developerdan.com/node-version-audit/ https://www.github.developerdan.com/node-version-audit/ [1] https://raw.githubusercontent.com/nodejs/Release/main/schedule.json https://raw.githubusercontent.com/nodejs/Release/main/schedu...
electroly 4y ago
Why didn't they foresee this before releasing Node.js 16? OpenSSL 1.1.1's lifecycle[0] was known well in advance of the Node.js 16 release. Why did they release it with an EOL date they could have known was impossible, and then later change the EOL date? This seems like a release engineering failure. Communication now is great but they had an opportunity to get this right from the beginning. As a result, we can all now be certain that Node.js's LTS support dates don't mean anything; they don't have the engineering discipline to make support promises they can keep. On multiple occasions now they've shortened their published LTS support periods after the fact. [0] http://web.archive.org/web/20210403090336/https://www.openssl.org/policies/releasestrat.html http://web.archive.org/web/20210403090336/https://www.openss... -- this is prior to Node.js 16's release
- sanjayio 4y ago
  I’d cut the Node team some slack, they’ve been doing phenomenally scheduling EOL and LTS support over the years. They’re notifying everyone 1.5 years in advance. They have some of the best backwards compatibility I’ve witnessed in software which means updating will be easy.
- linkgoron 4y ago
  I think that this is a quite harsh. The EOL for Node 16 is more than a year away, there's a good reason for the EOL change, and Node 18 will be LTS almost a year by then.
- saghul 4y ago
  Chill. To err is human. They are communicating this welll in advance so everyone has about a full year to update to Node 18 LTS. I’d say that is a very reasonable timeframe.
- joshmanders 4y ago
  You realize they have a schedule pattern right and they probably didn't realize openssl EOL was in the middle of a LTS lifecycle.
  - linkgoron 4y ago
_57jb 4y ago
I love this. I think to expect perfection in timing and aligning work done by humans, even where someone could make reasonable foresight arguments, is overlooking how challenging this wide level of supporting an ecosystem is. The response they made is in regards to security and making ut clear to users that they are expected to be anti-fragile to change. Even if the roadmap itself changes. I've changed decisions, even flip-flopped several times due to uncertainty. When at the heart of the message they are acting with positive intent, I applaud their short, sweet, and to the point message along with their reasoning. I worked with an organization that allowed TLS 1.1 for far too long because customers systems hadn't been updated. If they paid enough money, we had to allow it. Meanwhile we were getting beat up by the competition because, "Why would any good development company allow this?!?"
- Something1234 4y ago
  How does that work in their marketing? We are more secure cause we only use the latest protocol and deprecate things before our customers are ready?
  - _57jb 4y ago
    Equifax would like to have a word with you.
- deleted 4y ago
  [deleted]
0des 4y ago
- spoils19 4y ago
  Hard agree. As a community we need to stand up for our freedoms and stop using Node for any kind of application, since it's always inappropriate. I'll take you one step further and say that every instance of JavaScript usage is also unnecessary, even for an 'interactive' frontend (spoiler: most people don't care about interactiveness, just look at comments on this site). As a fun story, I was working in Node with a senior developer with 4 years of experience who wanted to use a library for a trie, instead of simply building one. Can you believe it? I fully implemented one in a half day to show my colleague how unnecessary it was, and we actually found a few issues with the library that my one didn't have.
  - nindalf 4y ago
    > just look at comments on this site Took advantage of HN's JS based interactivity to downvote your comment. I might not have if the interaction had required a page reload. See? JS solving a real world problem.
  - pessimizer 4y ago
    > Can you believe it? That's nothing. Somebody tried to get me to use git for source control, but I showed him by taking six months off to write my own source control system.
- deleted 4y ago
  [deleted]
forty 4y ago
According to https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/ (which has not been updated with the new schedule), nodejs 18 maintenance status will start on 2023-10-18, which means there will be a bit more than a month without a maintenance LTS version. It would be nice if they could also advance this date to match the new EoL of node 16 so people that are not interested in backported features can live their stable and regression-free life quietly :)
nilsbunger 4y ago
The biggest impact of this change is for organizations with big codebases who want to stay on LTS versions. With the canonical schedule you can do an upgrade every 2 years, skipping over every other LTS. eg you could go from Node 14 to Node 18 to Node 22. But with the early EOL, if you're on Node 16 you can't jump to Node 20, so you have to do an extra upgrade. For companies with big production codebases it can be a lot of work to qualify new releases. It would be great if the Node team pulls forward Node 20 LTS by 6 months to preserve the skip-every-other pattern. https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/
nindalf 4y ago
I don't know why people are complaining that they should have done things differently. 15 months is sufficient to migrate any application to Node 17. But let's be real, everyone on Node 16 is going to forget about this and panic next August. Then it'll take a Herculean effort by a few heroes in each company to pull off the migration under a tight deadline of a few weeks.
- solardev 4y ago
  > 15 months is sufficient to migrate any application to Node 17. If you don't work in tech, it's hard to explain to the higher-ups why some big software upgrade that will result in no user-facing improvements needs to take months off your million-dollar product launch. Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later, lol
  - ostenning 4y ago
    > Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later Its a sad reality of web development unfortunately
- 8n4vidtmkvmk 4y ago
  are node version upgrades a big pain? i haven't used it for anything enterprise level. only hit a few quirks here and there with some deps. i just drop back and wait for library maintainers to fix.... but i guess if you are that library maintainer it sucks
- cersa8 4y ago
  I've yet to experience a painful Node.js update. Backwards compatibility has been very good.
javajosh 4y ago
As an aside, what is the obstacle to wider LibreSSL (https://www.libressl.org/ https://www.libressl.org/) adoption, including node? Have the original SPOF and code quality issues been resolved by OpenSSL?
vbezhenar 4y ago
Why not support OpenSSL? It's unlikely that something terrible will happen in those 6 months and if it happens, just patch it.

102 points by WalterSobchak 4y ago

sparrish 4y ago

A bad situation with no good solution. I guess moving the EOL was the least sucky thing to do.

sanjayio 4y ago
To be fair, upgrading Node hasn’t historically been tough.
- forty 4y ago
  I agree for recent history at least. With that said, recent releases also haven't brought life changing changes either, so the incentive to upgrade remain low even if it's mostly painless.
- solardev 4y ago
  M1 added a lot of headaches to that... some older libs don't support newer Nodes running in native Apple Silicon mode :( Upgrading from 16 to 18 on Windows or Linux took me like 2 minutes of resolving some conflicts. That same repo took several days of investigation on M1, and eventually I gave up...

bcjordan 4y ago

AWS Lambda[0] and GCP Functions[1] both say they support only up to Node 16 today. Hopefully they'll get new versions shipped with enough lead time for customers to upgrade ahead of the deprecation. (There are things like Cloud Run to bring your own container that could be used sooner) [0]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.h... [1]: https://cloud.google.com/functions/docs/concepts/nodejs-runtime https://cloud.google.com/functions/docs/concepts/nodejs-runt...

iends 4y ago
This is largely because Node 16 is the current LTS.
- FBISurveillance 4y ago
  Node 16 graduated to LTS on 20 Apr 2021. Lambda added support for Node 16 just last month, basically 13 months after. I hope they add Node 18 sooner than that.
  - akmittal 4y ago
    Node 18 will be active LTS in October this year. So they will have 11 month of buffer
  - rantallion 4y ago
    AWS have already openly admitted that they were slow bringing Node 16 support and plan to be quicker next time round. > We recognize that customers have been waiting for some time for this runtime release. We hear your feedback and plan to release the next Node.js runtime version in a timelier manner. https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-now-available-in-aws-lambda/ https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-no...
mhoad 4y ago
I don’t know the AWS ecosystem but in the meantime on GCP at least just use Cloud Run rather than Cloud Functions and keep whatever run time you want and pick up a bunch of other benefits in the process. Their latest version of Cloud Functions is actually using Cloud Run under the hood already.
- explaingarlic 4y ago
  Cloud Run introduces a heap of other considerations at the enterprise level - container building and repository management which may not be managed by your team etc. Cloud Functions/Lambda are very nice in a company where you don't necessarily have access to making your own AMI, or container image etc. At least that's what we used them for at my old job. Still had to deal with some level of corporate tech indirection (E.G. We couldn't make the API gateway however we wanted, our account had no access to route53 etc.), but much less than with containers. It was just a quicker way to get code running.

jtwebman 4y ago

I feel they should make Node.js 18 lts sooner than when they do these. That way people have time to switch if they only use lts.

leipert 4y ago
NodeJS becomes LTS in October. That leaves people 11 months to switch. It is out right now albeit not LTS, so you can prep the switch and switch as soon as it becomes LTS. If they’d move to LTS a month earlier, not a whole lot of people would gain something from it.
- forty 4y ago
  Some people like using Maintenance LTS, which only gets security and bug fixes (as opposed to Active LTS which can also get backported features)

barelysapient 4y ago

Great communication from the team. Here’s our choices. Here’s our thinking. Here’s what we decided and why. Not ideal but it’s still over a year from now which gives folks time to plan.

lightswitch05 4y ago

It seems like the most reasonable choice. Incidentally, I have an open-source tool called Node Version Audit [0] which checks a given node version against known CVEs and end-of-life dates. It looks like the official change hasn’t been made yet [1]. [0] https://www.github.developerdan.com/node-version-audit/ https://www.github.developerdan.com/node-version-audit/ [1] https://raw.githubusercontent.com/nodejs/Release/main/schedule.json https://raw.githubusercontent.com/nodejs/Release/main/schedu...

electroly 4y ago

Why didn't they foresee this before releasing Node.js 16? OpenSSL 1.1.1's lifecycle[0] was known well in advance of the Node.js 16 release. Why did they release it with an EOL date they could have known was impossible, and then later change the EOL date? This seems like a release engineering failure. Communication now is great but they had an opportunity to get this right from the beginning. As a result, we can all now be certain that Node.js's LTS support dates don't mean anything; they don't have the engineering discipline to make support promises they can keep. On multiple occasions now they've shortened their published LTS support periods after the fact. [0] http://web.archive.org/web/20210403090336/https://www.openssl.org/policies/releasestrat.html http://web.archive.org/web/20210403090336/https://www.openss... -- this is prior to Node.js 16's release

sanjayio 4y ago
I’d cut the Node team some slack, they’ve been doing phenomenally scheduling EOL and LTS support over the years. They’re notifying everyone 1.5 years in advance. They have some of the best backwards compatibility I’ve witnessed in software which means updating will be easy.
linkgoron 4y ago
I think that this is a quite harsh. The EOL for Node 16 is more than a year away, there's a good reason for the EOL change, and Node 18 will be LTS almost a year by then.
saghul 4y ago
Chill. To err is human. They are communicating this welll in advance so everyone has about a full year to update to Node 18 LTS. I’d say that is a very reasonable timeframe.
joshmanders 4y ago
You realize they have a schedule pattern right and they probably didn't realize openssl EOL was in the middle of a LTS lifecycle.
- linkgoron 4y ago

_57jb 4y ago

I love this. I think to expect perfection in timing and aligning work done by humans, even where someone could make reasonable foresight arguments, is overlooking how challenging this wide level of supporting an ecosystem is. The response they made is in regards to security and making ut clear to users that they are expected to be anti-fragile to change. Even if the roadmap itself changes. I've changed decisions, even flip-flopped several times due to uncertainty. When at the heart of the message they are acting with positive intent, I applaud their short, sweet, and to the point message along with their reasoning. I worked with an organization that allowed TLS 1.1 for far too long because customers systems hadn't been updated. If they paid enough money, we had to allow it. Meanwhile we were getting beat up by the competition because, "Why would any good development company allow this?!?"

Something1234 4y ago
How does that work in their marketing? We are more secure cause we only use the latest protocol and deprecate things before our customers are ready?
- _57jb 4y ago
  Equifax would like to have a word with you.
deleted 4y ago
[deleted]

0des 4y ago

spoils19 4y ago
Hard agree. As a community we need to stand up for our freedoms and stop using Node for any kind of application, since it's always inappropriate. I'll take you one step further and say that every instance of JavaScript usage is also unnecessary, even for an 'interactive' frontend (spoiler: most people don't care about interactiveness, just look at comments on this site). As a fun story, I was working in Node with a senior developer with 4 years of experience who wanted to use a library for a trie, instead of simply building one. Can you believe it? I fully implemented one in a half day to show my colleague how unnecessary it was, and we actually found a few issues with the library that my one didn't have.
- nindalf 4y ago
  > just look at comments on this site Took advantage of HN's JS based interactivity to downvote your comment. I might not have if the interaction had required a page reload. See? JS solving a real world problem.
- pessimizer 4y ago
  > Can you believe it? That's nothing. Somebody tried to get me to use git for source control, but I showed him by taking six months off to write my own source control system.
deleted 4y ago
[deleted]

forty 4y ago

According to https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/ (which has not been updated with the new schedule), nodejs 18 maintenance status will start on 2023-10-18, which means there will be a bit more than a month without a maintenance LTS version. It would be nice if they could also advance this date to match the new EoL of node 16 so people that are not interested in backported features can live their stable and regression-free life quietly :)

nilsbunger 4y ago

The biggest impact of this change is for organizations with big codebases who want to stay on LTS versions. With the canonical schedule you can do an upgrade every 2 years, skipping over every other LTS. eg you could go from Node 14 to Node 18 to Node 22. But with the early EOL, if you're on Node 16 you can't jump to Node 20, so you have to do an extra upgrade. For companies with big production codebases it can be a lot of work to qualify new releases. It would be great if the Node team pulls forward Node 20 LTS by 6 months to preserve the skip-every-other pattern. https://nodejs.org/en/about/releases/ https://nodejs.org/en/about/releases/

nindalf 4y ago

I don't know why people are complaining that they should have done things differently. 15 months is sufficient to migrate any application to Node 17. But let's be real, everyone on Node 16 is going to forget about this and panic next August. Then it'll take a Herculean effort by a few heroes in each company to pull off the migration under a tight deadline of a few weeks.

solardev 4y ago
> 15 months is sufficient to migrate any application to Node 17. If you don't work in tech, it's hard to explain to the higher-ups why some big software upgrade that will result in no user-facing improvements needs to take months off your million-dollar product launch. Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later, lol
- ostenning 4y ago
  > Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later Its a sad reality of web development unfortunately
8n4vidtmkvmk 4y ago
are node version upgrades a big pain? i haven't used it for anything enterprise level. only hit a few quirks here and there with some deps. i just drop back and wait for library maintainers to fix.... but i guess if you are that library maintainer it sucks
cersa8 4y ago
I've yet to experience a painful Node.js update. Backwards compatibility has been very good.

javajosh 4y ago

As an aside, what is the obstacle to wider LibreSSL (https://www.libressl.org/ https://www.libressl.org/) adoption, including node? Have the original SPOF and code quality issues been resolved by OpenSSL?

vbezhenar 4y ago

Why not support OpenSSL? It's unlikely that something terrible will happen in those 6 months and if it happens, just patch it.