Require Node.js 16

Confirmed locally with Node 12 that yarn install fails with CKEditor 5 v32:

error @ckeditor/ckeditor5-alignment@32.0.0: The engine "node" is incompatible with this module. Expected version ">=14.0.0". Got "12.22.9"

However I think this will also require work on the testbots as they also seem to only be running Node 12.

We should definitely do this in 10.0.x and 9.4.x

Not sure about 9.3.x since if our own ci breaks, then it might break someone else's - could we maybe announce in advance and delay the change until we have something concrete to backport?

Opened #3261753: Update Node.js to v16 on DrupalCI in the DrupalCI queue.

Is it worth future-proofing ourselves a bit, especially as this is only a dev dependency, by going to Node 16 now - which is the current LTS version.

For Drupal 10, we'll almost certainly want to go to Node 16 or higher during its life, whether we do it in 10.0 or wait till 10.1.

For Drupal 9.4, it's an interesting question because Node 14 goes EOL in April 2023, whereas Drupal 9.4 will need to be supported until Nov 2023. So on the one hand, that's a potentially strong reason to jump to Node 16 now. On the other hand, assuming that everything that we ship with 9.4.0 works on Node 14, do we expect to have to add anything in a patch release of 9.4 that would require Node 16? For example, does CKE5 drop security support of its old majors when it releases a new one? If so, we'll probably want the ability to keep CKE5 current even within 9.4.x patch releases, which might require Node 16 towards the end of 9.4's life.

Postponed on #3261753: Update Node.js to v16 on DrupalCI. Putting out an announcement per #4 while we wait in the meantime is a good idea, once we decide on whether to go to 14 first and 16 later, or skip 14 and go straight to 16.

For example, does CKE5 drop security support of its old majors when it releases a new one?

https://github.com/ckeditor/ckeditor5/security/advisories/GHSA-3rh3-wfr4... seems to indicate yes.

In my view, I think that means we should go straight to 16, so NW for that. However, I'm open to arguments, if people have them, about why we shouldn't go to 16 yet.

I think it would be good to bump the requirement to Node.js 16 since in practice this should only impact core developers. IIRC we skipped one LTS in #3107918: Require Node.js 12 too.

I think we may want to consider backporting this to 9.3.x. I think when we worked on updating away from Node.js 8, we noticed that around the time an LTS becomes EOL, there are many packages dropping support for that version. Node.js 12 EOL is before Drupal 9.3.x EOL. Ideally we would be on a supported Node.js version to be able to update to latest versions of our dev dependencies in case there are security releases.

There are also strategic reasons why it would be beneficial for us to be able to backport #3261600: Update to CKEditor5 v32.0.0, because presumably more people are testing CKEditor 5 with Drupal 9.3.x than with 9.4.x.

nodejs 16 makes sense to me for 10.0.x and 9.4.x, I think we can just go ahead and do that.

The 9.3.x backport not as sure about, but that doesn't affect 10.0.x/9.4.x commits.

There are also strategic reasons why it would be beneficial for us to be able to backport #3261600: [PP-1] Update to CKEditor5 v32.0.0, because presumably more people are testing CKEditor 5 with Drupal 9.3.x than with 9.4.x.

In addition to getting more testers, the other advantage of getting 9.3.x onto CKE5's latest major is so that if they issue an SA, we can release that in our own SA without that SA also having to be the one to bump CKE5 several majors forward and Node.js forward. Bumping Node.js in a patch release is disruptive, but it will be even more disruptive if we have to do it in an SA.

On the other hand, there's a chance that CKE5 won't issue an SA during 9.3's lifetime, in which case we might be able to get away with not disrupting 9.3.x now or later. That would be nice, but it's a gamble.

I guess there's also the question of can we get onto the latest release of CKE5 in 9.3 without requiring a newer Node.js for all core developers / CI systems, and instead make it only conditionally required for people/tests who are building CKE5-related assets? I don't know enough about npm/yarn to know if that's feasible though.

I guess there's also the question of can we get onto the latest release of CKE5 in 9.3 without requiring a newer Node.js for all core developers / CI systems, and instead make it only conditionally required for people/tests who are building CKE5-related assets? I don't know enough about npm/yarn to know if that's feasible though.

It seems like with CKEditor 32.0.0 in package.json, it isn't possible to run yarn install with Node.js 12. I guess we could do a very dirty work around for this and not commit the package.json and yarn.lock changes, and just commit the changes to the built files similar to what we used to do before we moved all JavaScript dependencies to package.json.

I always think CKE5 and other similar tools should have their own package.json and don't mess the CORE package.json. (even only download/HDD size, I care about it)

Of course, if you look at the whole picture, no diff. You still need node14. But for me, I don't need the CKE5 compile to do my Drupal development or even Core contributions

The lucky thing is..... at THIS MOMENT, node 14 / 16 are pretty safe for us to use. But at my whole nodejs development experience, sometimes I really locked to upgrade my global node for a while.

And as a Windows user, I rejected to use nvm (or smiliar) tool, so I must lock the upgrade.

I did some research on the impact of changing our Node.js requirement in Drupa core / DrupalCI.

Impact of changing minimum requirement in core/package.json: low

Updating the Node.js version impacts any process where yarn install is being executed in the /core directory. We don’t ship Drupal core in npm, meaning that there isn't a proper way to extend /core/package.json without using yarn link, which is only designed for local development.

A majority of the tooling that requires Node.js is specific to Drupal core development. The exceptions are that DrupalCI provides an abstraction for running eslint and Nightwatch on contributed projects. Nightwatch could be also used by custom CI pipelines like Travis CI and Gitlab CI. It’s likely that majority of this is done on DrupalCI, which would likely not be impacted by this because we would always have to ensure that DrupalCI is running a supported version of Node.js.

There is also a workaround which allows executing some of the commands for files outside of the Drupal /core directory, when running the command inside /core directory and passing the path to a file outside of /core. However, the documentation is specific that the tooling is designed for Drupal core.

I walked through pages of contrib projects and discovered that there are projects that are using this workaround for updating JavaScript files in their projects. They would have to update their development environment to the version that core requires to be able to update their contrib project JavaScript files. If that isn’t feasible for them, they could simply pull an older tagged release that would not require Node 16. However, the vast majority of these were projects that haven’t changed these files in years. The projects that were more active and/or had any more advanced use cases had defined their own package.json with their own set of tooling, and wouldn’t be impacted by Drupal core development Node.js requirement.

There are some projects that are directly referencing our JavaScript build tooling, i.e. core/scripts/js/babel-es6-build.js. However, that file has been marked as internal since it was introduced in 2016, in #2818409: Convert Babel ES6 Compile script to NODE Script. Even these projects wouldn’t run into issues unless we explicitly started using Node.js 16-only features.

There are no projects directly executing commands from our package.json in their drupalci.yml.

Based on seeing how contrib ecosystem is using core’s tooling, there seems to be only minimal disruption caused by changing the Node.js requirement in our package.json. This would impact custom CI pipelines using Nightwatch testing. This would also impact developers doing core JavaScript development, who would be required to update their Node.js version either way since we don’t accept patches that would only change 9.3.x.

Impact of changing the Node.js version in DrupalCI: very low

I still believe that this is the change that has the highest change to disrupt contributed projects. However, this would only become a problem if contrib started using Node.js on DrupalCI. At the moment there’s only 7 projects in the whole ecosystem that are installing yarn dependencies in DrupalCI. Based on that, I wouldn’t give too much consideration to this.

If we see more of the community starting to use Node.js in DrupalCI, we should consider supporting multiple Node.js versions at the same time. However, this will likely be resolved by moving to use Gitlab CI.

Risks in not requiring supported version of Node.js: major

Same as with PHP, in JavaScript our Node.js requirement has to match that of our upstream dependencies. For example, if we still support Node.js 12, but an upstream package requires Node.js 14, it means that we are unable to update to that release. This means that after April 30, 2022, Drupal 9.3 will still be the recommended Drupal 9 release, but Drupal core won’t be able to keep its JavaScript dependencies up-to-date.

CKEditor 5 was our first dependency which we wanted to update, but couldn’t because it had already dropped support for Node.js 12. This means that Drupal 9.3.x is on an unsupported CKEditor 5 major, since only one major version is supported at a time (we know this won’t work once we ship Drupal 9.4 and 10 — we’re working with them to get longer security support). This impacts end users who are testing CKEditor 5.

There is a way to disable the engine check with yarn install –ignore-engines. This would still prevent anyone from installing yarn dependencies with Node.js 12 without using the --ignore-engines flag, meaning that we would effectively require Node.js 14.

With the previous Node.js LTS releases, we saw that some packages are dropping support for a given Node.js version immediately after it’s EOL. This means that we could have more dependencies which we are unable to update to the latest versions. The risk caused by this could be reduced by the fact that most of the development is happening on development branches, which we are able to keep up to date until the first stable release of the version, when we would always already have a new development branch.

Proposal

Node.js 12 is EOL by the time Drupal 9.4.0 has been released, meaning that the requirement needs to be something newer than Node.js 12. If Drupal 9.4.x is the LTS and supported until late 2023, the required version needs to be Node.js 16. Otherwise it could also be Node.js 14, but we would have to require Node.js 16 in Drupal 9.5.x. To simplify things, it would be ideal to require Node.js 16 in Drupal 9.4.x too.

Node.js 18 won’t be released by the time Drupal 10 is released unless Drupal 10 is released in the December fallback time. Based on that, Drupal 10.0 will likely have to depend on Node.js 16.

Changing the required Node.js version in Drupal 9.3.x could potentially impact CI processes using Nightwatch. We should continue supporting installing yarn dependencies with Node.js 12 because there could be custom CI pipelines utilizing core’s Nightwatch testing. Look for a solution that would not explicitly require Node.js 14, but would still allow us to install CKEditor 5. This could be splitting out CKEditor 5 from the main package.json to its own in 9.3.x.

Moving forward, to ensure the Node.js version is supported for the full lifetime of a minor, we should revisit the minimum Node.js requirement for each minor before tagging a RC on that minor.

tl;dr: Require Node 16 on both branches that are open for active development (9.4.x and 10.0.x) and continue requiring Node.js 12 on 9.3.x which is backports only.

Links

• Node.js release timeline
• Drupal core release cycle

Critical as Node 12 is EOL and we need this for CKEditor, but postponed because DrupalCI needs to be upgraded first in #3261753: Update Node.js to v16 on DrupalCI

@Mixologic in the linked infra issue

Okay, I've got php74->8.1 updated, as those are the ones that are already on debian buster. I dont know if I can make this work for earlier versions (7.3)

Sending PHP 7.4 and above for retests to check this out, but we ideally need PHP 7.3 as well.

Oops, #2 is for Node 14, let's try for Node 16.

I think we still need a change record and a draft release note.

Based on that, I think the release note will probably be sufficient.

I had to update from node 14 to node 16 to commit the patch :P

Don't think a CR is useful here, the error message you get from yarn is pretty clear, it's a development dependency, the release note is good.

Committed/pushed to 10.0.x and cherry-picked to 9.4.x, thanks!

Issue summary says we're leaving 9.3.x as is, so doing that. We can re-open to discuss more if necessary.

I think we should file a follow-up for #31. Basically I think we need to figure out a way to update CKEditor 5 without explicitly requiring Node.js 14.

Moving to 9.3.x for now so I don't think I forgot to push a commit every time I see it.

Do we already have an issue for discussing if/how we're going to keep CKE5 updated in Drupal 9.4? As in, do we plan to upgrade its major version in Drupal patch releases in order to keep it security supported? Seems like deciding on that is also relevant to what we need with respect to Drupal 9.3.

do we plan to upgrade its major version in Drupal patch releases in order to keep it security supported?

I assume #36 means the answer to this is 'yes, until Drupal 9.4 itself goes EOL we'll keep backporting ckeditor updates from Drupal 10'? This would probably be better in its own issue so it's easier to find later though.

Yep, we should file a separate issue to decide how we'll keep CKE5 updated in 9.3 until its EOL (and then we can mark this closed against 9.4).

I have a workaround in mind that will probably allow us to update CKEditor in 9.3.x, will post patch for that in #3261600: Update to CKEditor5 v32.0.0. Marking this as fixed since this is something that we probably should deal with in the CKE specific issue since based on #17, this shouldn't be backported to 9.3.x.