NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros

[theofficialgman]

What is the problem this feature will solve?

Moving to RHEL 8 has raised the glibc version being linked against
(2.28). The official Node.js Linux release binaries will only run on
Linux distributions with a matching or higher version of glibc.

#42659
nodejs/build#2815
nodejs/build#2741

What is the feature you are proposing to solve the problem?

Building on one of these older distros. All of them have support well past the EOL of NodeJS 18 when paired with paid or free (through sponsorship) extended support.

The breaking change that has been implemented will cause many projects dependent on NodeJS to drop centos 7, rhel 7, and (more importantly) Ubuntu bionic and Ubuntu 18 (bionic in snaps).

One of the most important projects dependent on nodeJS 18 using bionic or an older distro is Electron https://www.electronjs.org/docs/latest/faq#when-will-electron-upgrade-to-latest-nodejs This of course will trickle down to 1000s of dependent projects. Many developers use the official nodejs binaries in their projects

if we compare the linux support to window support, we can clearly see that linux is the least backwards supported platform requiring glibc 2.28 which released in August 1st 2018 (and wasn't included in distros until even later), while Windows has support for versions going back to 2015 for tier 1 support.

you say:

we do not want to have to make a disruptive change
towards the end of Node.js 18's life cycle.

when this would actually be the best thing to do. support the LTS versions for as long as the LTS version support exists. You can of course support it further than the LTS distros are supported (by purchasing or using the sponsored extended support).

What alternatives have you considered?

Notify all open source projects on github to NOT use NodeJS 18 through a custom github bot and to remain on prior NodeJS releases (eg, 16.x) until absolutely necessary.

[cobalt2727]

This would also solve nodesource/distributions#1392 - right now, the NodeSource build system is shipping completely broken packages to users, and has been for over a month now, with no official response given as to how this will be addressed.

[rapito]

Albeit upgrading some linux distros to newer versions because of security updates and such would practically "get rid of the issue", some CI tools (in my case running on Ubuntu 18.04) depend on some scripting pipelines made in nodejs. It's dependency of glibc is breaking builds and automated pipelines on many environments for me.

Notably this is not addressing any real security patches or updates that would justify forcing glibc on the OS.

[targos]

@nodejs/build

[bnoordhuis]

One good reason for dropping support for CentOS/RHEL 7 is glibc. CentOS 7 ships with glibc 2.17 but node's dependencies are moving to newer versions.

(In fact that already happened but we're working around it for now. Not a viable long-term strategy though.)

Ubuntu 18.04 ships with glibc 2.27. That's probably new enough to last until v18's EOL.

[rvagg]

Some background can be found in nodejs/build#2815, and specifically on this @ nodejs/build#2741

But the headline is this:

• "CentOS-7 updates until June 30, 2024"
• Node.js 18.x EOL on 2025-04-30

Unfortunately this happens on a regular cadence, we have to deal with this every few years, as do other major projects. It sucks for users, I hate it as someone who maintains a few systems on ancient versions of Linux. But you have the option of building Node.js yourself - if you can - V8 is going to get in your way over time here as it moves faster in its minimum requirements than we probably would be and we've regularly been forced to up our minimums just to support V8 (sometimes we manually patch to maintain backward compatibility!).

[cobalt2727]

nodejs/node-v8#220
V8 requires 2.27, no? What other dependencies, if any, are getting in the way?
nodejs/build#2815 (comment)
And if you guys have ESM licenses, all the more reason to continue to target 18.04.

[itmustbe]

I also wish that there had at least been a warning that Node 18.x.x was incompatible with CentOS 7. And I'd certainly cast a vote for maintaining compatibility with CentOS 7 and similar distros if possible!

Although I'm only a tinkerer with Linux, I do have a significant non-profit website running on my little server. I try to keep everything up-to-date on my server, and during a routine update of Node.js, I encountered the dreaded 503 error on the website I'd just updated (thankfully a staging site).

I've rolled back to 17.9.0 for the foreseeable future, but it always makes me nervous having things like Node.js getting more and more out-of-date.

CentOS 8 is something I'm planning on, but it requires planning and time to migrate, and I will not have the time to dedicate to that project for awhile yet. I also lack the knowledge on building Node.js myself.

[mhdawson]

There was a warning in the release blog post - https://nodejs.org/en/blog/announcements/v18-release-announce/#toolchain-and-compiler-upgrades.

@itmustbe for the future what do you think would have been the best channels to use in advance of the release itself to get the news out?

[cobalt2727]

Once again, V8 is a non-issue for 18.04. They're explicitly still supporting 18.04 by making the target glibc 2.27, which 18.04 runs with.

[mhdawson]

@cobalt2727 I think the comment above in #43246 (comment) sums it up well. There are a number of different factors that went into the decision available (build team resources, support time lines, deps, future risk, etc.) and with a supported version of Node.js 16.x being available for another 2 years it's the balance we chose between the needs of the project and ends users.

[cobalt2727]

I would like to invite you guys to reconsider and reread the original post - breaking support for an OS that's perfectly capable of running NodeJS has a high chance of causing problems in thousands of projects for anyone on 18.04 for whatever reason well before before EoL hits. The balance you're describing only works if projects just... don't use 18 for a while, and lose out on feature updates until then.

So far, other than a misunderstanding of V8 requirements, I don't see the issue with continuing to provide official builds for 18.04. May as well put those ESM licenses to good use, yeah?

[richardlau]

We don't have ESM licenses. nodejs/build#2815 (comment) mentions that they were not followed up on.

[itmustbe]

I appreciate there are many aspects to Node.js development that I don't closely follow, and probably should have.

What happened in my case is that I run a virtual private server on CentOS 7 with Virtualmin/Webmin, and an update was flagged "Version 18.2.0 is available". Nothing stopped me from pushing the button to update Node.js on an unsupported system, and I rather wish something had done, as the website in question immediately went down with a 503 error for now-obvious reasons (not supporting the latest GLIBC etc. owing to the outdated version of libstdc++).

I contacted the folks who manage Virtualmin/Webmin, and they will be locking old distros to the correct version of Node.js so that this doesn't keep happening to other people in similar situations.