Upgrade to webpack 4

[EECOLOR]

We need to check this information: https://github.com/webpack/webpack/releases

It seems this release has a similar approach for chunking modules. The CommonsChunkPlugin was removed so it's not weird to think this version would break our chunk plugins. Potentially this could be positive as we might be able to switch to the built-in version.

More information about the removal of CommonsChunkPlugin here: https://gist.github.com/sokra/1522d586b8e5c0f5072d7565c2bee693

[EECOLOR]

This will be an adventure... Got a few hours in and I'm probably not close. Diffing 3 and 4 is not really an option because of the massive amounts of change.

[EECOLOR]

See this comment?

It took quite some effort to obtain that knowledge. But (from that comment):

If a core member of the webpack team ever reads this: Please, refactor this stuff, it makes watching at the clock and understanding what time it is while under the influence of magic mushrooms look easy.

I am not yet sure, but they might have read this comment, hehe. We'll see...

[EECOLOR]

For future reference, on Linux I had to do: sudo apt-get install autoconf libtool pkg-config nasm build-essential and remove node_modules and yarn.lock to rebuild some native stuff that comes with imagemin.

The error I had was: /node_modules/mozjpeg/vendor/cjpeg: error while loading shared libraries: libpng16.so.16: cannot open shared object file: No such file or directory

[EECOLOR]

webpack/watchpack#25

https://github.com/webpack/webpack-dev-middleware/pull/250/files

It's been some weeks since this was opened and webpack/watchpack/issues/25 is still an ongoing issue with no resolution. This has been merged as a stop-gap until watchpack is updated to handle the scenario. Once that issue is resolved, this change will be reverted.

[EECOLOR]

Too bad some documentation is missing: webpack/webpack.js.org#1968

[EECOLOR]

Phew, that was an adventure!

But it seems I have it in working order again. It's funny to look back at the emotion curve:

• Let's hope the update will not be so bad
• Ouch, everything is broken
• Oh fuck, that will be tricky
• Oh no, I don't think it's realistic to think I can fix this in a reasonable amount of time
• Hmm, looks like we're stuck with webpack 3 for quite some time. We might need to consider an alternative
• Hey, this one is solvable
• Ahh, so we can fix this too
• Ohw, that's what's causing it
• I might be able to fix it
• Yeah, almost there
• Oh wow, only deprecation messages left
• Whoohoo, it all seems to work

In some more detail. The changes to webpack are really an improvement. It seems they have refactored the code I was referencing in an earlier comment and that the SplitChunksPlugin is very similar to what we had. So the shared modules plugin is gone 😄.

With its current configuration it generates an extra runtime for each chunk, we could possibly improve it so it will have similar behavior as before.

TODO:

• Update source-map (https://github.com/mozilla/source-map/blob/0.7.1/CHANGELOG.md). In my mind "new SourceMapConsumer now returns a Promise" doesn't make any sense but we'll see.
• Move the options for the web compiler out of react-universal-plugin and run the WebpackOptionsDefaulter against them.
• Refactor the tapAsync into tapPromise to cleanup the various degrees of what they call 'callback hell'.
• We might want to switch to async-await in some cases, but I will have to check the build servers to see if they run nodejs 8.
• Fiddle a bit (timeboxed) with the runtimes.
• It's probably a good time to adjust react-universal-client-loader so a future bug ("can not have more than one of the same ?universal component on the same page") will be prevented. It might however be smarter to move this to a separate branch / issue. Kinda depends on the runtimes thing.
• Check all new (and undocumented) options to make sure they don't mess things up.

[EECOLOR]

For now we can't switch to the newest source-map until we have checked all build servers:

Drop support for Node < 8. If you want to support older versions of node, please use v0.6 or below.

[EECOLOR]

https://medium.com/webpack/webpack-4-mode-and-optimization-5423a6bc597a states:

Runtime chunk ... This chunk should be inlined into the HTML

[EECOLOR]

Note to self: don't forget to add a breaking change entry for manifest.json.

[EECOLOR]

It seems the last commit has fixed the runtime problem (probably because of WebpackOptionsDefaulter). I don't think inlining it is actually required for now. We would safe a single request, but we would increase the bytes of the html file by more than the limit we set for individual chunks.