Bringing Forward the End-of-Life Date for Node.js 16 | Hacker News Reader

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

nodejs.org

102 pointsWalterSobchak41 comments

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?!?"

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?

Equifax would like to have a word with you.

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.h...

[1]: https://cloud.google.com/functions/docs/concepts/nodejs-runt...

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.

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.

I should have mentioned this in the original post but the missing piece of the puzzle to help close that gap is Buildpacks https://buildpacks.io/ which gets you out of the path of having to think about creating containers and again AFAIK is what Cloud Functions is using under the hood.

This is largely because Node 16 is the current LTS.

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.

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-no...

Node 18 will be active LTS in October this year. So they will have 11 month of buffer

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.

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/

[1] https://raw.githubusercontent.com/nodejs/Release/main/schedu...

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.

> 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

> 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

I've yet to experience a painful Node.js update. Backwards compatibility has been very good.

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

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

To be fair, upgrading Node hasn’t historically been tough.

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...

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.

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.openss... -- this is prior to Node.js 16's release

According to your linked article:

> The OpenSSL 3.0 release schedule is documented on the OpenSSL 3.0 Release Schedule wiki page. We expect the final release to be in early Q4 2020.

Node 16 Release date:

> 2021-04-20

They gave themselves 3-6 months buffer from 3.0 release to Node 16 release, and decided to move forward when OpenSSL was 4-6 months behind schedule, with no idea when 3.0 would release

OpenSSL was then released in SEPTEMBER of 2021, nearly a year late, and 4 months after Node 16's LTS start date.... As of April, the Node team could not know if OpenSSL was going to be released tomorrow, next month, or next year

I think they made the right choice to keep moving forward instead of halting work waiting on OpenSSL to get back on schedule... by April 2021, when SSL 3.0 was already ~5-6 months behind, I would have expected them to extend support for 1.1.1 for another few months... they didn't but that's mostly a moot point -- OpenSSL has committed to security fixes through the Node 16 end-of-life.. but the Node team isn't comfortable with that, so they made a change

It seems I didn't make my suggestion clear, since you seem to be arguing against a point I didn't make. I'm saying they could have, and should have, announced the shortened LTS period when they released Node 16, after having already made the decision to ship with OpenSSL 1.1.1. The support period for OpenSSL 1.1.1 was known at the time -- why did it take this long for them to notice and pull back their LTS date accordingly? It could have been known on the day of Node 16's release. The important part of LTS releases is being able to make plans around firm dates; the specific length isn't important as long as it's known up front.

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.

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.

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.

You realize they have a schedule pattern right and they probably didn't realize openssl EOL was in the middle of a LTS lifecycle.

The dates were known in advance - however, the Node.js team expected OpenSSL 3 to be out before the release of Node 16, but it didn't happen - so they had to release with OpenSSL 1.1.1. I think that there was some minor hope of maybe upgrading, but obviously it was too backwards-compatibility breaking to land without a new major.

https://github.com/nodejs/TSC/issues/1222 https://github.com/nodejs/TSC/pull/859

>known was impossible

It's not impossible. They just have to support more.

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.

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.

Some people like using Maintenance LTS, which only gets security and bug fixes (as opposed to Active LTS which can also get backported features)

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

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/

According to 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 :)

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

Reply on news.ycombinator.com