Bedrock: Switch from Gulp to Webpack

[alexgibson]

Description

Back in 2019 we researched and prototyped switching bedrock to use Webpack. At the time we didn't prioritize making the effort to actually switch over, as it wasn't something that had any real weight behind it and we had other priorities. I think it's now time to prioritize making a switch:

• Bugs such as https://github.com/mozilla/bedrock/issues/9700 are slowing down front-end dev work.
• Gulp is not as actively maintained today as it once was.
• Webpack has a large open source community around it today, and might be more familiar to new hires and contributors.

---

Success Criteria

• [ ] Front end build system is run using Webpack.

[Abhra303]

@alexgibson how would you compile Sass files in webpack with the current file structure?
As far as I know, webpack uses import statements in js files to automatically detect which files to be compiled (so the path of sass files also have to be manually included into the corresponding js file). And all this thing have to be done manually . With such a huge number of js files and sass files, it seems impossible!
Besides this, sass files will finally convert to javaScript language (not css). Would not it become very complex ?

[alexgibson]

@Abhra303 not really, Webpack supports multiple entry points, so it's possible to pass it a reference to static-bundles.json and compile it like we do today. I already have a working branch building the site this way. To extract CSS file from the Sass source files you can use the mini-css-extract-plugin.

[Abhra303]

@alexgibson thanks. I am new to webpack. Did not know about this aspect. I would love to see the code as it will let me learn something new :)

[pmac]

I'm told that https://parceljs.org/ is the cool new kid on the block for this stuff.

But I'm also wondering whether we really need to be bundling CSS and JS files anymore. HTTP2 has solved many of the perf issues we were trying to solve with bundling, and having more smaller files might improve the likelihood of a user having one of the base files cached .

[alexgibson]

I've taken a look at Parcel, but I think there's a currently a greater range of options / community support for Webpack. We could certainly take it for a spin though.

In terms of http/2 making bundling obsolete, I'm not sure I agree entirely. Http/2 does great things to help optimise the number of concurrent requests between the client / server, but bundling today does a lot more (things like transpiling, removing unused code, minification). Larger bundles also compress a lot better than many small ones, so what actually ends up being faster is not so clear cut.

[alexgibson]

I found a good article from Khan Academy that goes into this a little: https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/

[pmac]

Yeah, we'd obviously still have to compile and minify and things, but I do wonder whether, especially with Brotli compression we get from the CDN, it would be better to have better cachability than purely a lower number of bites on the page. It would take experimentation and probably a better understanding of our traffic than we currently have. If it's close though, and bundling makes our developer UX worse or takes a lot of our maintenance time, then that aspect might make it's worth an even harder question.

[alexgibson]

I'm all for doing some experimentation, just saying that lots of folks have also done the same and published info on this (and things like Webpack and Parcel probably wouldn't have happened). Cachability is good, but most people don't browse around our site and only hit really one or two pages at most. Like the Khan Academy post above suggests, the solution is often a balance between bundles and requests.

That said, I'm all for making our build process simpler and with less burden to maintain. But what we have right now makes me nervous for the stability of our codebase long term. It's already pretty complex, takes a lot of maintenance, and provides a buggy (and outdated) developer UX. We really need to improve on what we have imho. And either way, we'll still need something to do all the other non-bundling tasks.

[stephaniehobson]

I looked into http2 back when I was on MDN and found that the number of concurrent requests limit (6-8ish) was still a thing. If that's still the case there's a need for some balance between requests and bundling.

[pmac]

Sounds good. Hopefully we can get on it sooner than later.