Support for webpack 4

[marcofugaro]

Webpack4 is currently in beta has been released, quite some things changed.

Taking a look from the changelog, here is what needs to be done in order to support webpack 4:

• Add a mode block, I imagined it something like mode('production', { minimize: false }) since

  You can configure this in detail with the flags in optimization.* (build your custom mode)

• Update the uglify block, now under optimization.minimizer[0]
• Update the devServer block (NamedModulesPlugin plugin)
• webpack-dev-server has been deprecated in favour of webpack-serve
• extract-text-webpack-plugin is deprecated for CSS in favour of mini-css-extract-plugin
• Upgrade all dependencies (wait for the plugins to release new versions)

thank you! I probably missed something else...

[andywer]

Thx for opening the issue, @marcofugaro!

I like the mode block proposal.

[vlad-zhukov]

It looks like we are going to have a major bump of webpack-blocks with the webpack 4 support. @andywer what do you think about finalising v1 and start working on v2?

[marcofugaro]

I forgot to add, there is probably the need for an optimization block of some sort.
An example would be optimization({ sideEffects: false }) or a way to configure optimization.splitChunks, but I'm not sure how to go about it.

[vlad-zhukov]

@marcofugaro is't the mode block you proposed works like this?

[marcofugaro]

@vlad-zhukov yeah but optimization contains stuff also not related and not influenced by the mode.
splitChunks and sideEffects are the only two I could find. Search for optimization in the new changelog

[andywer]

@vlad-zhukov Yeah, I totally agree. We can take webpack-blocks as it is and make it the final v1.0.0. Can then do a major bump for webpack 4.

I am just terribly busy and have little time. Help from all contributors is highly appreciated 😊

[dmitmel]

@marcofugaro Could you, please, outline which features need to be done in order to support webpack 4?

[marcofugaro]

@dmitmel what do you mean? All of them are necessary

[dmitmel]

@marcofugaro

what do you mean?

I want to open a PR so I must know what features to add.

All of them are necessary

Do you mean features described in the issue description?

[marcofugaro]

Do you mean features described in the issue description?

Yup.

[dmitmel]

I'm working on webpack 4 features but I'm stuck with the mode block. I have some ideas on how this block can be used:

1. To simply set the mode (well, in this case, a better name for this block would be setMode).
2. To configure optimization settings based on the current mode. This would require a setMode function for setting mode and adding it to the context.

Any thoughts?

P.S. I personally like more the first idea because we already have env function for setting env-based settings.

[dmitmel]

How do you think, should NODE_ENV be used as the default value for mode?

[andywer]

How do you think, should NODE_ENV be used as the default value for mode?

I'd say explicit is better than implicit, so let's set the mode()/setMode() explicitly to production or development. There is no more need to set NODE_ENV in the config then, too, since:

(webpack 4 changelog; mode config:) process.env.NODE_ENV are set to production or development (only in built code, not in config)

But it might make sense to put the mode into the context, anyhow, since it's a pretty important setting that you might want to react to in other blocks as well.

[vlad-zhukov]

I'd make the mode block also take a second parameter optimization instead of introducing 2 blocks.

mode('development', {
	splitChunks: 'all',
});