On Tue, Jan 23, 2018 at 4:34 PM, Gregory Szorc <g...@mozilla.com> wrote:
> Speaking as a maintainer of the Firefox build system, we try to be > conservative about the set of dependencies required to build Firefox from > source. We recognize that every required dependency is a potential source > of failure and complexity. Dependencies can create complications for > packagers. From a build system perspective, it's in our best interest to > minimize the dependencies required to build Firefox. > > Our desire to keep things simple can be at odds with the wishes of Firefox > developers who wish to leverage new and exciting tools and technologies. In > short, the policy of minimizing build dependencies can externalize costs > onto overall Firefox development by hindering people from using better > tools. This adversely affects the development velocity of Firefox and can > cause product quality to suffer. > > For a few years now, various pockets of Firefox development have wanted to > use Node.js as part of the development workflow. I wouldn't say they > directly want to use Node.js: they want to use the large ecosystem of tools > built around Node.js. But that's splitting hairs. Our build system policy > has been that leveraging Node.js and its ecosystem for supplemental > workflows is fine, but shipping a build dependency on Node.js is not. Many > Firefox developers are now using Node.js in their day-to-day workflow for > things like running ESLint. We're using Node.js in CI. But we're not > forcing people to have Node.js installed to build Firefox. > > Various groups have routed around the limitation that Node.js can't be > required to build Firefox. There are now Firefox features that do require > Node.js to build. However, the output from the Node.js tools is checked > into the Firefox source repository. So from the perspective of the Firefox > build system, Node.js doesn't exist and therefore isn't a build dependency. > > The status quo is not ideal. The more people I speak with, the more > apparent it is that our current policy of not allowing Node.js tooling in > the build system is causing more problems than it is preventing. Speaking > as the build system module owner and someone who cares about developer > workflows, tooling, and developer productivity, I don't think the current > policy is good for Mozilla. > > I'd like to start a discussion about requiring Node.js to build Firefox. > > What do I mean by "require Node.js?" Let's assume I mean having a usable > Node.js executable on the host system to be used during a Firefox build. > > What about npm or a package manager? I would strongly prefer to limit the > required dependency to Node.js itself. While the Firefox build system would > depend on 3rd party packages and tools (such as Babel), I'm pretty > insistent (as a build system maintainer) that these dependencies be > vendored into the Firefox source repository so as to not incur a run-time > dependency on a packaging service. I've seen the chaos that "left-pad" > caused. I don't fully trust the security model of JavaScript package > distribution. I don't think we can risk the ability to build Firefox or the > integrity of the Firefox product by the availability and integrity of a 3rd > party packaging service. That may sound like a harsh thing to say. But it's > the posture we've applied elsewhere (such as to Python packages and PyPI). > So, this means that all JavaScript executed by Node.js as part of the build > would either be provided by Node.js itself or the Firefox source > repository. If we needed to use a package manager as part of the build, > that package manager could be vendored in the Firefox repository along with > other JavaScript libraries (not unlike how we currently vendor Python's pip > package manager). > > A few people at Mozilla have poked at this problem already. We have a > general sense of where some pain points for us will be. We know that > getting modern versions of Node.js installed on various distributions > requires using 3rd party package repositories. We know that Windows support > could be painful. We know that installing common packages can result of > dozens if not hundreds of dependencies being added. We know this could lead > to us having to install thousands of files as part of the Firefox build - > an overhead I'm not keen on seeing. We know all of this can add up to a > significant amount of overhead to support. (Yet it still feels like a > lesser problem than having people work around not being able to use Node.js > directly.) > > What we don't generally know is the impact requiring Node.js would have on > downstream packagers. Our adoption of Rust last year was a long and > sometimes painful process. I have a feeling that requiring Node.js would be > a similar experience. But like Rust, I feel that adopting Node.js is in the > best long-term interest for Firefox development velocity and product > quality. I'm reluctant to cause more hardship by introducing a new build > dependency. But it's very difficult to keep saying we can't use Node.js in > the Firefox build system. I wish I could say "we'll build SpiderMonkey and > use that instead." Unfortunately, many Node.js tools don't work with > SpiderMonkey, so that's not an option. Plus there are difficulties with > cross-compilation. As sad as it makes me to say it, SpiderMonkey is not an > option: Node.js is the only viable option. > > If we require Node.js to build Firefox, what are the requirements, > desires, and hardships of downstream packagers and consumers of the Firefox > build system? Keep in mind that mozilla-central right now is Firefox 60. > That will become ESR 60 in May. > Quick follow-up. First to add mozilla-linux-taskforce. Second to note that we almost certainly wouldn't make a change before Firefox 61. That would give everyone only caring about ESR an extra ~1 year to deal with fallout.
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
