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',
});

[dmitmel]

@vlad-zhukov It's better two use two blocks because each of them has a different task.

[marcofugaro]

@dmitmel Some of the options in optimization will override the ones set by the production or development mode, so it makes sense to make it more explicit in the mode block.

From the changelog:

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

Those options are optimization.minimize, optimization.noEmitOnErrors, optimization.concatenateModules, optimization.namedModules and probably some more, they canged based on the mode.

Making it more explicit leads to less buggy webpack config.

I think it should be supported both an optional parameter in the mode block and an optimization block for mode-independent features like optimization.splitChunks

[dmitmel]

@vlad-zhukov @marcofugaro The second parameter for mode is great when there are separate configurations for development and production. I didn't understand you at first because I put webpack config for both prod and dev into one file if there are a lot of common settings.

[dannyphillips]

Any updates on this?

[vlad-zhukov]

Updated the OP message with the webpack-serve.

[dmitmel]

@dannyphillips Upgrade to webpack 4 requires a lot of breaking changes in webpack-blocks, so we have to release a new major version (v1.0 -> v2.0).

[vlad-zhukov]

As I pointed in #279, Extract Text Plugin is deprecated for CSS in favour of mini-css-extract-plugin. Do we need to keep the extract-text block in v2? What are the other use cases for it?

[andywer]

Would be fine to me to replace extractText by extractCSS (?). But also not sure if there is still some common use case for the extract-text plugin.

[andywer]

FYI: Published v2.0.0-alpha with webpack 4 support.

Install using npm install --save-dev webpack-blocks@next.

[diego-toro]

I found and error using devServer without entryPoint:

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.entry should be one of these:
   object { <key>: non-empty string | [non-empty string] } | non-empty string | [non-empty string] | function

After taking a look at the devServer code seems like the Webpack's default "entry" is being replaced with nothing.
Any fix for that? Maybe the block's "entry" default shouldn't be there since Webpack 4 defaults it to 'src/index'?

EDIT: I removed the "entry" from the block default values and it's working.

[dmitmel]

Hmmm, why does the devServer block add an entry in the first place? Isn't this a job for the entry block?

[diego-toro]

@dmitmel yep, maybe for a silent error or something? check this lines: 25 and 50
I'd say it's not necesary default "entry" as nothing anymore under devServer.

[diego-toro]

Anyways, I thinks since webpack-dev-server is replaced with webpack-serve it's simply better not to use devServer and create a serve.config.js file for custom configurations and start using the new script

...
"scripts": {
    "start": "webpack-serve",
},
...

[vlad-zhukov]

@IngenieroLata Does webpack-serve work for you? I tried to write a block for it some time ago but couldn't make it start running.

[diego-toro]

@vlad-zhukov yes it works for me, but there are certain options that only work with the command line. webpack-contrib/webpack-serve#237

I think webpack-serve docs are not clear about which options can be under cosmiconfig and which ones doesn't.

...
"scripts": {
    "start": "webpack-serve --log-level error",
},
...

On the other hand, the hot-client seems to have some issues webpack-contrib/webpack-serve#218

[marcofugaro]

Hey, I tried to update the mini-css-extract block but couldn't figure out all the logic that is inside the current extract-text block, and was afraid I might mess something up.

Here is a basic block of the mini-css-extract-plugin if anyone wants to take a stab at it.

const MiniCssExtractPlugin = require('mini-css-extract-plugin')

function extractCss(options) {
  return (context, util) => util.merge({ 
    module: {
      rules: [
        Object.assign({
          test: /\.css$/,
          use: [
            {
              loader: MiniCssExtractPlugin.loader,
            },
          ],
        }, context.match)
      ]
    },
    plugins: [
      new MiniCssExtractPlugin(options),
    ],
  }
}

// usage
extractCss({
  filename: 'app.[contenthash:8].css',
  chunkFilename: '[name].[contenthash:8].chunk.css',
})

[marcofugaro]

Welp, they did a 180 and deprecated webpack-serve instead.

https://github.com/webpack-contrib/webpack-serve

[andywer]

Well, less work for us... 🙈🙈

Thx for pointing out!

[Telokis]

May I ask what the status of this issue is?
It seems that everything has been resolved (considering the extractCss snippet three post above mine)

[andywer]

Thanks for pointing out, @Telokis! Yes, I think that issue has been resolved long ago.

If anyone likes to disagree (but I sincerely doubt that), now is your chance 😉