Page MenuHomePhabricator

Quibble: Update nodeJS to at least v14.18.0
Open, HighPublic

Description

Quibble's images used in ci-fullrun are using 14.17.5, which breaks a GrowthExperiment script (T332386: Error: Cannot find module 'node:fs') that relies on the node: prefix for e.g. node:fs, which was backported from node 18 to node 14.8.

Until we do that, Quibble's CI is broken.

Event Timeline

kostajh added a subscriber: hashar.

From the other task:

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 \
kostajh triaged this task as High priority.Wed, Mar 22, 1:11 PM

Blocking CI and merges to Quibble.

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.

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

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 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.514.21.3 :-\

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

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

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

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.