On Wednesday, January 24, 2018 at 11:10:06 AM UTC-8, Nicholas Alexander wrote:
> If we really want to avoid a build time dependency on NPM, then I think we > should think through a small set of build system primitives that we want to > support and not really think about NPM-based tooling at all. That is, can we > support Babel, WebPack, ES lint, and perhaps Flow, for arbitrary NPM packages > checked into the tree? (And vendor those hard dependencies into the tree.) > If we can do that, we might even be able to stretch to running those > _limited_ dependencies in SpiderMonkey with the help of WebPack or browserify > or some other Node.js-in-the-browser conversion, plus special sauce for > SpiderMonkey and our build environment. This would be a reasonable strategy for a situation in which we want to integrate a third-party project whose build process relies on Node but don't otherwise want to use Node ourselves. Then we might do the minimum necessary to support that build process without enabling more general use of Node in the build system. An (imperfect, to be sure) example of that approach is the way we added minimal support for GYP in order to integrate some third-party libraries that depended on it. (We've since discovered other uses for GYP, and improved support for it, so the approach has changed over time.) However, I don't think that's the situation we're in currently. Rather, the breadth of Firefox projects using Node, and the breadth of Node features (+ NPM packages) they're using, suggests that our strategy should accommodate more general use of Node (and evolution of its use). > As sad as it makes me to say it, SpiderMonkey is not an option: Node.js is > the only viable option. As a SpiderNode contributor (and fanboy), I reluctantly concur. Even if we could kludge together a solution for the subset of Node (+ NPM packages) in use today (which itself seems like a stretch), it wouldn't have the same developer ergonomics and would be inflexible in the face of evolving usage patterns. Maybe it'll be possible to run Node (or Node packages) on SpiderMonkey one day, but Node itself is the only viable option for the foreseeable future. -myk _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
