Upgrade to Webpack 4

[thekonz]

As you might have already seen: Webpack 4 beta is out

This beta release is pretty much stable and will be released as such in a month.

As promised, we will wait a month from today before releasing webpack 4 stable

The new release offers a lot simpler configuration and better compression. This should reduce the amount of code in encore and yield better results in production.

[Lyrkan]

This should reduce the amount of code in encore

That would be the case if we drop Webpack 2 and 3 compatibility... which is probably ok for new projects but would prevent existing projects from updating Encore easily.

Making it work with both Webpack 2, 3 and 4 may not be easy though based on some of the changes listed on this page: webpack/webpack#6357

[seyfer]

It is released today
https://medium.com/webpack/webpack-4-released-today-6cdb994702d4
waiting for the update 🎆

[weaverryan]

Yep! We just need someone to create a PR :). Also, some libs we depend on may not yet be compat with 4, but we’ll find out with a PR. Volunteers? It’ll get done faster that way ;)

[enguerranws]

@weaverryan What do you need in that PR? I started upgrading Webpack version and resolving module dependencies errors, ran yarn test (no errors in the output), but what can I do more to help on this?

Really looking forward to use Encore with Webpack 4 👍

[andrewtch]

Same question here @weaverryan - what do you expect in the PR? As I've tested only extract-text-plugin breaks 4.0 support.

[enguerranws]

@andrewtch For the moment, I fixed extract-text-plugin breaking by fixing its version to "extract-text-webpack-plugin": "4.0.0-beta.0".

[Lyrkan]

Hi @enguerranws,

I'd say that if you have something that works with Webpack 4 you can already create a PR for it.
That'll help to see if something more is needed :)

I'm really interested to see how you handled some of the other things that changed in this version (such as the new mode option and the removal of CommonsChunkPlugin and UglifyJsPlugin).

Does your version still works with Webpack 3 by the way ? (even though I'm not sure we should keep supporting it, WDYT @weaverryan ?)

[stof]

Well, the new mode option maps directly to our concept of Encore.isProduction(), so this is probably the easiest part of the migration.

[stof]

I would be totally fine with requiring webpack 4 for a new version of Encore, assuming it is a semver major (which would be the case anyway as we are pre-1.0). Maintaining both support for version 3 and 4 in parallel would probably be a nightmare, especially given that the npm ecosystem does not resolve a common versions of deps (so we might end up having webpack 4 installed as a dependency of Encore and webpack 3 installed as a dependency of something else, or the opposite...). It might create more issues than what it solves. People needing to stay on Webpack 3 would have to do some special things anyway to force their whole no_modules to stay on v3 once Encore supports v4. It might be much simpler to tell them to stay on the previous version of Encore, and to upgrade when their other plugins are compatible with webpack 4.

[stof]

for the CSS, we should migrate to https://github.com/webpack-contrib/mini-css-extract-plugin for Webpack 4

[Lyrkan]

Well, the new mode option maps directly to our concept of Encore.isProduction()

@stof From my understanding it is used to enable some loaders/plugins presets (source maps, minification, etc...). It could make some things from the Encore API a bit awkward since we also have methods that directly control these kind of things (especially enableSourceMaps).

That's why I was wondering if it wouldn't be better to use mode: "none" and keep handling everything ourselves.

[weaverryan]

Initially, I think Stof has a good point about creating a new version of Encore that only supports Webpack 4. Most users don’t care about the underlying version anyways.

At this point, we just need to create a PR and start hacking on it. It’s been on my list (probably you to @Lyrkan), just haven’t gotten to it yet.

But I would love to do this soon and be progressive :).

[stof]

Well, the goal of Encore is to make webpack easier to use. If webpack 4 gives us sensible defaults for the dev and prod modes, we may want to deprecate our own APIs enabling the sourcemaps for instance, and relying on the webpack decision (that even means less code to maintain for us).
Webpack 4 introduced modes to make their configuration easier, which is also what we want to achieve in Encore. It totally makes sense to have some of our APIs becoming obsolete thanks to the underlying work.

[enguerranws]

Initially, I think Stof has a good point about creating a new version of Encore that only supports Webpack 4. Most users don’t care about the underlying version anyways.

I totally agree on that. Since @Lyrkan pointed that up, I'm thinking of cases and projects that would need a Webpack 4 "Webpack 3 compatible". Didn't find it out.