Universal and Webpack 4 — a tale of two builds

After setting up a pretty fantastic POC Node infrastructure with stunning code-splitting and an incredibly easy way to code-split for developers, it was safe to say that I was pretty happy with my little experiment. Patching issues along the way to make Universal ready for large-scale, intricate systems.

But then Webpack 4 was released. Webpack 4 pretty much re-wrote all things chunking, considering we were a code spitting system… Universal didn’t work when I attempted to update. Game over?

The Universal Family now supports aggressive code-splitting!

As of June 4, 2018,We released a major update of babel-plugin-universal-import which now Supports Webpack 4 As of June 5, 2018, We released a major update of extract-css-chunks-webpack-plugin which now Supports Webpack 4 As of June 12, 2018, We released a major update of webpack-flush-chunks which enables developers to use Universal with more complex / aggressive code-splitting tactics.

So, how did we solve this?

Pretty much, extract-css-chunks-webpack-plugin was the main issue… We needed a Webpack 4 solution to CSS chunking.

We all know Webpack is slated for better CSS handling at some point in the future. We dont know when but nobody seems to be saying its anytime soon. So we cant bank on vaporware

Check out out the Universal family (start here): https://github.com/faceyspacey/react-universal-component

I’m sure you are thinking, “Just use mini-css-extract.” Yeah. I tried that, and it did the job of code splitting CSS, but there was no Hot Module Reloading (HMR)…. Ouch

“But there’s style-loader, just use it for dev builds!”

Well yeah, there is that. But c’mon

No Source Maps

Cant edit styles in chrome devtools

String injection into the DOM

Styles overwriting styles as more inline code is appended.

Not something reputable companies like

The use of style-loader

At Fiverr, or any large company, there’s some common sense goals I aim to achieve.

Within the scope of CSS, here’s what I want:

I mprove DX and mitigate risk .

and . Avoid as much inconsistency between local and production.

Avoid hard to debug CSS, additional memory and slowdowns in the client.

CSS, additional memory and in the client. Don’t interfere with CSS’s cascading goodness ( keep styles in an inheritable order)

Improve long term cacheing

Speed up builds

You need dev builds to function as close as possible to production builds. You need a good end-to-end system that stands up to the heat of high traffic. Relying on a build that isn’t as close as it can be to production opens you up to risk you may only catch after you deployed a $100k mistake.

Whats the point in a great system if the DX (Developer Experience) is not where it needs to be? I looked around at how to make mini-css-extract hot reload. Quite frankly, I was disappointed, not by the great work of Sokra, but by the fact that its just more work and still clunky. I just want it to work. Like seriously, what doesn’t HOT reload these days 😂

The solution

Essentially we took mini-css, changed it up a little, and added Automatic HMR injection into it.

But why? And why not just PR it back to Webpack?

A valid question. I’ll answer it in two parts.

Why use mini-css-extract and modify it?

The API is familiar, less friction & drop-in replacement.

It’s well written, fast, simple.

Webpack’s author was involved directly.

Why not PR Webpack?