NodeJS 14 is EOL

[CSC-swesters]

Judging by this page, NodeJS 14.x was end-of-lifed on 2023-04-30. The RHEL8 family is still using it, however. See e.g. this line in the ood-packaging repository.

RHEL8 seems to have NodeJS 16 available as a module too (based on dnf module list nodejs output), so that could be an easy fix, since RHEL9 already requires %{nodejs} >= 1:16.0, %{nodejs} < 1:18.0. However, that will only be a short-term fix, since NodeJS 16 is going EOL in October of 2023. The more sensible thing would be to move towards NodeJS 18 or 20, which still have support until at least 2025.

Can you share your plans on how to move forward with the NodeJS roadmap? Thanks in advance!

[johrstrom]

As you indicate support will be specific to the OS. I'd imagine that EL8 will continue to release security patches. Though if I just check ruby on our EL7 system it's from 2015...

The node development team sets it to EOL, but I'd ask if the RHEL team does the same.

In any case - I will use this ticket to make a determination for what version/OS combinations we can use in 3.1 (the next version) that are likely to be stable for some time and not force us to update a dependency in 3.1.x patch versions.

So I guess that'd mean, as you indicate, using the highest version available for that OS. I don't believe we use any node features that would make us choose this version or that.

@treydock do you have any thoughts? I can't seem to find any RHEL docs on how long they'll support security patches for say nodejs 16.

[CSC-swesters]

It would seem to me that Red Hat won't do any support of their own. I found this page indicating that users are responsible for choosing a NodeJS version that is supported: https://access.redhat.com/articles/3376841

"Node.js 14 LTS End of Support as of April 30, 2023"

And in that section:

"In order to be running in a supported configuration, Red Hat build of Node.js must be running on a supported Node.js LTS release and supported environment."

Let me know if I've interpreted this incorrectly.

[CSC-swesters]

New finding, let me correct myself.

That page says that "RHEL8.7 or later" is a supported configuration for NodeJS 18 LTS. I verified this with a Rockylinux 8.7 container as well:

# dnf module list nodejs
...
Rocky Linux 8 - AppStream
Name                     Stream                   Profiles                                                Summary                             
nodejs                   10 [d]                   common [d], development, minimal, s2i                   Javascript runtime                  
nodejs                   12                       common [d], development, minimal, s2i                   Javascript runtime                  
nodejs                   14                       common [d], development, minimal, s2i                   Javascript runtime                  
nodejs                   16                       common [d], development, minimal, s2i                   Javascript runtime                  
nodejs                   18                       common [d], development, minimal, s2i                   Javascript runtime                  

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

Why is the upper version limit needed in the ondemand-nodejs package? I would think that removing that would allow sites to choose their own NodeJS, based on availability (e.g. NodeJS 16 for RHEL8.6, and NodeJS 18 for RHEL8.7). The minimum version can of course stay, based on what the OOD applications require.

[treydock]

For RedHat appstream EOL dates are all on one page: https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle. The EOL dates from the upstream vendor almost never matter with RedHat as RedHat will continue to back port security fixes if the appstream is still supported.

One issue, OnDemand still supports RHEL 7 and there is not any SCL NodeJS higher than version 14. OnDemand 3.1 will be last release to support RHEL 7 so this isn't that big a deal.

[treydock]

The packaging infrastructure change to use NodeJS 18: OSC/ondemand-packaging#248. Once that's merged I'll update this repo to pull in those changes.