Update to webpack 4

[edmorley]

Webpack 4 has now been released. Whilst their docs have not yet been updated (eg webpack/webpack.js.org#1856 and friends) - it would be good to start looking at what we need to do to support webpack 4 soon.

I propose something like:

1. Review/merge any open non-breaking-change PRs (including those from Renovate)
2. Publish a new Neutrino 8.x release and make sure the release/v8 branch is updated
3. Alter master to be Neutrino 9 dev/alpha/whatever, making it ok for breaking changes (we can still ship urgent Neutrino 8.x bugfix releases later, but from the release branch)
4. Merge any remaining Renovate PRs that are breaking but don't drop support for webpack 3, so we pick up webpack 4 fixes to deps
5. Update webpack-chain to support any new webpack 4 options
6. Vet all of our deps to see if there are any that don't yet support webpack 4
7. Open a PR to add webpack 4 support to Neutrino master (and include updates to deps that dropped webpack 3 support)
8. After a few iterations on the PR (and once it's clear the webpack 4 docs/best practices have stabilised), merge to master
9. Release a Neutrino 9 alpha
10. Once Babel 7 is released and we've updated to that (#316), release Neutrino 9 beta/final...

Anything I've missed? :-)

[eliperelman]

:clap: That sounds like a great plan!

[edmorley]

Vet all of our deps to see if there are any that don't yet support webpack 4

I haven't checked all the deps yet, but one that is definitely not ready yet is: webpack-contrib/extract-text-webpack-plugin#701 (there is an alpha, but judging by other issues filed in that repo, is still buggy)

[Bnaya]

The future is https://github.com/webpack-contrib/mini-css-extract-plugin extract-text-webpack-plugin is (about to be) deprecated

[edmorley]

1. Review/merge any open non-breaking-change PRs (including those from Renovate)
2. Publish a new Neutrino 8.x release and make sure the release/v8 branch is updated

These two are now done (8.2.0 just published), so barring any objections I'll start merging breaking changes into master (with master now being treated as 9 alpha).

[edmorley]

I've started working on this locally. Changes so far:

• I've cherry-picked the various open dependency update PRs that we couldn't yet take on master (since they drop support for webpack 3)
• I've removed packages/chunk/* and the use of ModuleConcatenationPlugin, since the new webpack chunk/production optimizations options make them redundant
• I've removed the NODE_ENV config entry from the env preset, since webpack 4 now sets defines it by default (this kind of makes the env preset overkill vs just using the plugin directly, but presumably we should keep it around for now)

Left to do:

• add support for the new options (eg mode, optimization) to webpack-chain
• switch from extract-text-webpack-plugin to mini-css-extract-plugin since the former doesn't support webpack 4
• sort out minification (the config options all changed, and we need to make a decision as to babel-minify vs uglify-es)
• set optimization.splitChunks.chunks: "all" (since it's superior to the webpack 4 default; they didn't want to break certain use-cases that don't affect us)
• make the necessary changes to html-template so it handles the new webpack 4 chunking options
• update the docs
• ...and no doubt some other things that will come up along the way

[edmorley]

@eliperelman, what are your thoughts on how Neutrino should handle the new mode option? eg:

• have each preset set it themselves manually (eg neutrino.config.mode(process.env.NODE_ENV === 'production' ? 'production' : 'development')
• have it be handled by the neutrino API instead and if users want to override then they have to do so via NODE_ENV?

[edmorley]

Oh and I guess we need to warn people against continuing to use the vendor entrypoint (since the new webpack splitchunks handles this). Options:

• print a warning but leave the entrypoint untouched
• fail early with an appropriate error
• try to remove the vendor entrypoint for them

I'm leaning towards the fail early option.

[eliperelman]

what are your thoughts on how Neutrino should handle the new mode option?

This first option sounds like the right way, even though it can lead to duplication. So each high-level project preset would need to set it:

• web
• node

I think those are the only ones where we would need to set it.

---

fail early with an appropriate error

Are there any valid use cases where vendor may still be used by someone, even when taking split chunks into consideration?

[eliperelman]

have it be handled by the neutrino API instead

What I am really trying to avoid with this approach is the need for the CLI/API to add its own middleware.

[edmorley]

There's now PR #809 open to update Neutrino to webpack 4 - if anyone subscribed to this issue has 20 minutes to try it out, the feedback would be really useful :-)