Status

()

Core
Build Config
2 years ago
2 years ago

People

(Reporter: selenamarie, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

This is meant to be a tracker for adding npm and node support. 

Collecting notes here: https://etherpad.mozilla.org/npm-and-node-in-build-system
Motivation and goal would be better pasted here than referenced through an etherpad link.

Comment 2

2 years ago
Keep in mind build machines don't have access to the outside world. Also, we want builds and test results to be reproducible over time. We'll almost certainly need to run our own internal package mirror so all packages referenced by the tree are available for all of time. Or, we can vendor dependencies in mozilla-central like we do for Python. The latter is preferred, as it doesn't introduce an external dependency beyond the base `node` and `npm` executables and there is no potential for "drift" over time.
Here's a straw-man take on a user story here:

As a Firefox module owner or peer, I should be able to easily use key high-quality npm packages (such eslint, react-tools, various css linters, etc) in the build process.  

Motivation: most of the JavaScript and web tooling energy these days is happening in the node/npm ecosystem.  There's an opportunity to help take our build-tooling to the next level using well-maintained, industry-tested packages where those are already available.

This probably needs more fleshing out in terms of what the acceptance criteria would be, but it's a start.
Depends on: 1211914
Any progress on this? This might become a critical part of building the Firefox developer tools. We are looking at processing our JS files on the fly, so we need to run packages on node to do this.
(In reply to Gregory Szorc [:gps] from comment #2)
> Keep in mind build machines don't have access to the outside world. Also, we
> want builds and test results to be reproducible over time. We'll almost
> certainly need to run our own internal package mirror so all packages
> referenced by the tree are available for all of time. Or, we can vendor
> dependencies in mozilla-central like we do for Python. The latter is
> preferred, as it doesn't introduce an external dependency beyond the base
> `node` and `npm` executables and there is no potential for "drift" over time.

Vendoring deps seems far easier and we'd be fine with that. I don't think we plan on using too many build-time node dependencies, so it shouldn't be hard to get what we need vendored.
One thing that has moved forward slightly is that it's now part of the Ubuntu testing images used in TaskCluster (https://bugzilla.mozilla.org/show_bug.cgi?id=1273695#c4) (thanks Selena for the heads-up on this).
You need to log in before you can comment on or make changes to this bug.