Upgrade the build version of NodeJS to version 14
Categories
(Firefox Build System :: Toolchains, task)
Tracking
(Not tracked)
People
(Reporter: standard8, Unassigned)
References
(Blocks 1 open bug)
Details
User Story
How to test locally: - Apply patch from Phabricator (attachment link in this bug) - Execute `MOZ_SCM_LEVEL=1 mach bootstrap` to get the Node 14 executables from the try servers - `mach build`, `mach lint -l eslint`, `mach lint -l eslint --fix` with dirty tree (ie prettier), etc.
Attachments
(1 obsolete file)
+++ This bug was initially created as a clone of Bug #1840850 +++
Splitting this out from bug 1840850, to simplify the overall upgrade. This is for bumping the build system to a not-so-out-of-date build, NodeJS 14 (so that Linux distros should be able to keep building reasonably easily).
|
Reporter | |
Comment 1•3 years ago
|
||
|
|
Reporter | |
Comment 2•3 years ago
|
||
|
||
Comment 3•3 years ago
|
||
Ubuntu 22.04 LTS seems to be stuck on nodejs 12.
|
|
Reporter | |
Comment 4•3 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #3)
Ubuntu 22.04 LTS seems to be stuck on nodejs 12.
Does this still matter if node can be vendored by ./mach bootstrap?
According to this: https://ubuntu.com/about/release-cycle, Ubuntu 22.04 will have "standard support" until 2027, and "expanded support" until 2032. I do not think we'll be able to keep building with Node 12 for that long.
I do not have the knowledge of the Linux areas. I am trying to help keep node up to date, so that we are not too far behind, especially with respect to security releases, and so that we'll be able to move onto newer versions of node packages, and tidy up old things (e.g. bug 1744958) with low friction. Therefore, please can the build team come up with a plan for how we manage NodeJS in the long term? I would like to avoid doing work that we're not ready for, but additionally I think we should have a regular update plan.
|
|
||
Comment 5•3 years ago
|
||
Didn't we agree that as long as the build still works with older nodejs version (which only use node for devtools/client/shared/build/build.js afaict), then we can have higher requirements for non-build stuff? (Even better would be for the build not to require node at all, but well...) I'm actually surprised that so many tasks still depend on node-12. At this point, I thought only tasks in taskcluster/ci/build/linux-base-toolchains.yml were using that...
|
||
Comment 6•3 years ago
|
||
There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:standard8, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 7•2 years ago
|
||
I'm sorry for the delay in getting back to this, other projects have taken priority over the last few months.
(In reply to Mike Hommey [:glandium] from comment #5)
Didn't we agree that as long as the build still works with older nodejs version (which only use node for devtools/client/shared/build/build.js afaict), then we can have higher requirements for non-build stuff? (Even better would be for the build not to require node at all, but well...)
I'm not sure we had explicit agreement. Looking back over old bugs, I found bug 1690377 comment 25 and bug 1762571 comment 12, but there may have been more. The part I think that has been missed from the discussions, is that whilst the use of node is probably safe, npm is also used. I'm not entirely sure, but I'm assuming the devtools code is installing modules via npm at build time, so that may need thinking about.
In any case, I would like to request that the build team produces something like the Rust update policy for Node, so that we can have a policy written down for the future.
It may also be best that the build team has the responsibility to ensure node is updated on a regular basis/at appropriate times. The work Dan and I have generally done previously has been not part of our main priorities.
I'm going to un-assign myself from this bug as it seems we cannot proceed until we have the policy.
I'm actually surprised that so many tasks still depend on node-12. At this point, I thought only tasks in taskcluster/ci/build/linux-base-toolchains.yml were using that...
I don't know enough about how it all works to provide an answer here. I would have expected that as it is part of the build that it would be on all platforms. The mochitest-plain instances do seem like they should be on the newer nodejs versions. I think the mozbuild python tests should be on the older version because they're testing the build (if node is needed at all there).
|
||
Updated•2 years ago
|
|
|
||
Comment 8•2 years ago
|
||
but I'm assuming the devtools code is installing modules via npm at build time, so that may need thinking about.
npm is not used by the build.
|
|
||
Comment 9•2 years ago
|
||
Actually, do we still need node at all? The only thing it's used for is to run babel on devtools, and from a cursory look, the main thing that changes is import statements, which have been supported by Firefox for a long while now...
|
|
Reporter | |
Comment 10•2 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #9)
Actually, do we still need node at all? The only thing it's used for is to run babel on devtools, and from a cursory look, the main thing that changes is import statements, which have been supported by Firefox for a long while now...
Just to acknowledge that I've seen this. It isn't an easy answer as there's additional parts of the code base that strictly speaking should currently be using node as part of the build, but haven't been set up for it.
I seem to recall part of the reason for the newtab code to bundle was because of performance, but we would need to verify if that is still an issue (and how big) or not.
I'm happy to start discussions about if we need it or not, though it might be a few weeks before we get a decision.
|
||
Comment 11•2 years ago
|
||
At one point, there was a bit of kicking around the idea of changing pdf.js vendoring to webpack it as part of the build process instead of vendoring it already bundled for better blame and easier backports. I assume that wouldn't be an option if node was removed from the build system.
|
|
Reporter | |
Comment 12•1 year ago
|
||
(In reply to Mark Banner (:standard8) from comment #10)
I'm happy to start discussions about if we need it or not, though it might be a few weeks before we get a decision.
I'm sorry, I haven't got around to this, and it isn't really on my radar at the moment. This is probably better asked to the desktop tech leads group, about how we want to manage node/react/jsx usage in devtools/newtab/asrouter/pocket/aboutwelcome components going forward.
Description
•