From the other task:

In T332386#8704881, @hashar wrote:

NodeJS 16 breaks the fibers node module which is a dependency of WebDriver.io dependency wdio-sync which is used by some repositories. Thus the NodeJS upgrade is blocked on T256626: Refactor WebdriverIO tests from sync to async mode

We are thus still on NodeJS 14 (precisely 14.17.5) which comes from releng/node14 image:

dockerfiles/node14/Dockerfile.template

ENV NODE_VERSION=v14.17.5-linux-x64

RUN {{ "curl" | apt_install }}

COPY SHASUMS256.txt /tmp/nodeinstall/SHASUMS256.txt
RUN cd /tmp/nodeinstall \
    && curl -Lo node-${NODE_VERSION}.tar.gz https://nodejs.org/dist/v14.17.5/node-${NODE_VERSION}.tar.gz \

In T332387#8717798, @kostajh wrote:

Blocking CI and merges to Quibble.

Your patch(es?) adding a requirement on ultra-bleeding-edge node features should be reverted.

I propose to Decline this; the node14 support is EOL, and efforts should go into the node16 migration.

In T332387#8718098, @Jdforrester-WMF wrote:

In T332387#8717798, @kostajh wrote:

Blocking CI and merges to Quibble.

Your patch(es?) adding a requirement on ultra-bleeding-edge node features should be reverted.

I don't think it's unreasonable for developers to expect a recent version of node 14 (our current version was released in August 2021).

In any case, reverting our patches would cause considerable difficulty, because we use it to build a Vitepress site for GrowthExperiments https://doc.wikimedia.org/GrowthExperiments/master/js/frontend/ as part of T329033: [Internship] Modernization of web interfaces using Vue.js; I am not sure how Codex is avoiding this problem as they have a simlar buildchain (cc @Sgs).

Change 902104 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[integration/config@master] dockerfiles: Update node14 image to 14.21.3

https://gerrit.wikimedia.org/r/902104

In T332387#8718101, @Jdforrester-WMF wrote:

I propose to Decline this; the node14 support is EOL, and efforts should go into the node16 migration.

I'm all in favor of moving to node16, but in the meantime, I'd like to see this fixed. So here is a patch to update to the latest node 14 version.

In T332387#8718105, @kostajh wrote:

In any case, reverting our patches would cause considerable difficulty, because we use it to build a Vitepress site for GrowthExperiments https://doc.wikimedia.org/GrowthExperiments/master/js/frontend/ as part of T329033: [Internship] Modernization of web interfaces using Vue.js; I am not sure how Codex is avoiding this problem as they have a simlar buildchain (cc @Sgs).

Codex is a non-MediaWiki project that has custom jobs with its images, not Quibble (and has been using node16 for a year now). You could build your Vitepress system off a different repo for this use case?

NodeJS 14 is end of life in a month April 2023 and is still receiving updates (ex: [[[ https://github.com/nodejs/node/commit/6aca711858cc8d4b011384977c543d65ed17aeab | 2023-02-16, Version 14.21.3 'Fermium' (LTS) ]] which is a security release).

What I am guessing is we are using 14.17.5 cause that is the version that was available at the time and we missed keeping up to date with the latest release. 14.17.0 got released in May 2021 or two years from now which sounds like an eon for nowadays developers. I think we should follow them a bit more closely.

We can't update the Quibble jobs to NodeJS 16 for now until we got rid of fibers / wdio-sync and I think it is unfair to hold everyone on that migration. Kosta has proposed a patch to update the CI images to the latest NodeJS 14 (14.21.3) and it might be fine to have. The big question is what kind of impact that will have on all the Node 14 based jobs and that is a big unknown, I bet a lot of those issues will also surface when we move to NodeJS 16 so one can see that as a preparing step.

Is it worse it? I can't tell the impacts of upgrading NodeJS 14.17.5 → 14.21.3 :-\

In T332387#8718320, @hashar wrote:

NodeJS 14 is end of life in a month April 2023 and is still receiving updates (ex: [[[ https://github.com/nodejs/node/commit/6aca711858cc8d4b011384977c543d65ed17aeab | 2023-02-16, Version 14.21.3 'Fermium' (LTS) ]] which is a security release).

What I am guessing is we are using 14.17.5 cause that is the version that was available at the time and we missed keeping up to date with the latest release. 14.17.0 got released in May 2021 or two years from now which sounds like an eon for nowadays developers. I think we should follow them a bit more closely.

We can't update the Quibble jobs to NodeJS 16 for now until we got rid of fibers / wdio-sync and I think it is unfair to hold everyone on that migration. Kosta has proposed a patch to update the CI images to the latest NodeJS 14 (14.21.3) and it might be fine to have. The big question is what kind of impact that will have on all the Node 14 based jobs and that is a big unknown, I bet a lot of those issues will also surface when we move to NodeJS 16 so one can see that as a preparing step.

So in practice, I think this would mean:

• merge the image update patch
• build the images
• make the JJB patch to use the new images
• revert the JJB patch if we see there are problems in CI
• revert the image update patch

which is a non-zero amount of work but maybe also not terrible?

In T332387#8718190, @Jdforrester-WMF wrote:

In T332387#8718105, @kostajh wrote:

In any case, reverting our patches would cause considerable difficulty, because we use it to build a Vitepress site for GrowthExperiments https://doc.wikimedia.org/GrowthExperiments/master/js/frontend/ as part of T329033: [Internship] Modernization of web interfaces using Vue.js; I am not sure how Codex is avoiding this problem as they have a simlar buildchain (cc @Sgs).

Codex is a non-MediaWiki project that has custom jobs with its images, not Quibble (and has been using node16 for a year now). You could build your Vitepress system off a different repo for this use case?

The static prototyping space in documentation/frontend is eventually going to be where we import components from for use in our MediaWiki code, and while a separate repo would be possible, it would add more complication and indirection than I'd prefer.

In T332387#8718320, @hashar wrote:

Is it worse it? I can't tell the impacts of upgrading NodeJS 14.17.5 → 14.21.3 :-\

We could upgrade in two steps: 14.17.5 → 14.18.0 as a way to minimize impact and start announcing and preparing for whatever next bump we decide to make 14.18.0 → 1X.X.X

In T332387#8718190, @Jdforrester-WMF wrote:

Codex is a non-MediaWiki project that has custom jobs with its images, not Quibble (and has been using node16 for a year now). You could build your Vitepress system off a different repo for this use case?

We could explore that option although the setup effort comes a bit inconvenient in time since the internship is already on-going. I find handy to hold a VitePress project within a MW extension repository to document frontend code in a live manner but I understand the infrastructure constraints.

Change 902104 merged by jenkins-bot:

[integration/config@master] Docker: [node14] Update node from 14.17.5 to 14.21.3

https://gerrit.wikimedia.org/r/902104

Mentioned in SAL (#wikimedia-releng) [2023-06-30T18:49:29Z] <James_F> Docker: [node14] Update node from 14.17.5 to 14.21.3 for T332387

Change 934604 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: [selenium-daily-*] Update to images with node 14.21.3

https://gerrit.wikimedia.org/r/934604

Change 934605 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: [quibble*] Update to images with node 14.21.3

https://gerrit.wikimedia.org/r/934605

Change 934604 merged by jenkins-bot:

[integration/config@master] jjb: [selenium-daily-*] Update to images with node 14.21.3

https://gerrit.wikimedia.org/r/934604

Change 934605 merged by jenkins-bot:

[integration/config@master] jjb: [quibble*] Update to images with node 14.21.3

https://gerrit.wikimedia.org/r/934605