How will this affect me?
Chances are reasonable that your version of Linux will just work. This particularly applies to newer versions of the distributions above, but likely applies to some other distributions as well.
Once `mach bootstrap --no-system-changes` (bug 1481693) lands in the tree, people can start testing and updating our compatibility spreadsheet. I’ll post to dev-builds, dev-platform, and firefox-dev when that happens.
If your OS version hasn’t been tested, please try running `mach bootstrap --no-system-changes`, and if there’s a problem, please update the spreadsheet and file a bug in Firefox Build System :: Bootstrap Configuration, and CC firstname.lastname@example.org. Patches, of course, are gladly accepted.
If we made a mistake, and there’s a version that you think needs to be in the “must works” list above, please file a bug in Firefox Build System :: Bootstrap Configuration, and CC email@example.com
What does the current schedule look like?
Thursday, August 9 (mc=63): `mach bootstrap --no-system-changes` can now install a Mozilla-private NodeJS toolchain in ~/.mozbuild (and developers/distros can start testing the bootstrap support)
Weds, August 15 (mc=63, 8 days before soft freeze): --enable-nodejs becomes the default for mozilla-central (distros or developers must install node; those who have issues can set --disable-nodejs, which will be valid until the early part of the 64 nightly cycle)
Make GO/NO-GO decision re riding trains
Tues, September 11 (mc=64): nodejs becomes a hard dependency for Firefox builds when --disable-nodejs is removed.
For those who want more detail about each of these steps, this work is being driven as part of an Activity-Stream project with a more in-depth roadmap
Can I set up and check my machine/distro beforehand to avoid problems once Node becomes a hard requirement?
What about node_modules and npm/yarn packages?
No new packages from the npm or yarn registries are landing as part of this patch.
In the immediate future, individual packages will be vendored in on a case-by-case basis.
Immediately after NodeJS lands, and before we start landing packages into the top-level node_modules, I’ll be drafting some straw-man policies for packages and their dependencies (i.e., specific details on what sorts of packages will be allowed, how we’ll handle security, licenses, etc). I’ll be posting to the usual places (mozilla.dev.builds, mozilla.dev.platform, firefox-dev) requesting comment and further discussion.
What’s next for Node in the tree?
The first customer for this code is expected to be DevTools, who will use a standalone version of Babel to transpile JSX to JS files as part of the build (bug 1461714), so that checking in JS build artifacts is no longer necessary. This will be a first step in making risk-analysis / bug-finding / uplifting more efficient for release engineers, sheriffs, and others.
Drafting, circulating, and iterating on the node_modules proposal described above.
Landing an initial prototype of a single node_module with dependencies (possibly PostCSS)
Where can I read a more detailed analysis as to why we’re doing this?
The detailed rationale, along with important tradeoffs and risks, are described in Nick Alexander’s Intent-to-require document, which was posted for comment to dev-platform and dev-builds in February. Note that a few parts of the document are out of date, and I’ve attempted to annotate those parts as comments in the document.
There is still a problem/concern/issue that I think needs to be addressed before the landing happens. What should I do?
Thanks muchly to a bunch of folks who have helped make this happen; most especially Nick Alexander and Greg Szorc, but also (in alphabetical order) Alexander Poirot, Chris Karlof, Jason Laster, Kate Hudson, Kim Moir, Mike Shal, and Tim Spurway. Apologies to anyone I’ve inadvertently forgotten!