Support for webpack 4 about webpack-blocks HOT 34 CLOSED

@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 😊

from webpack-blocks.

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.

from webpack-blocks.

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

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

from webpack-blocks.

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.

from webpack-blocks.

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.

from webpack-blocks.

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

from webpack-blocks.

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 😉

from webpack-blocks.

Thx for opening the issue, @marcofugaro!

I like the mode block proposal.

from webpack-blocks.

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?

from webpack-blocks.

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

from webpack-blocks.

@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

from webpack-blocks.

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

from webpack-blocks.

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

from webpack-blocks.

@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?

from webpack-blocks.

Do you mean features described in the issue description?

Yup.

from webpack-blocks.

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.

from webpack-blocks.

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

from webpack-blocks.

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

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

from webpack-blocks.

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

from webpack-blocks.

@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

from webpack-blocks.

@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.

from webpack-blocks.

Any updates on this?

from webpack-blocks.

Updated the OP message with the webpack-serve.

from webpack-blocks.

@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).

from webpack-blocks.

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?

from webpack-blocks.

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.

from webpack-blocks.

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

from webpack-blocks.

@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.

from webpack-blocks.

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",
},
...

from webpack-blocks.

@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.

from webpack-blocks.

@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

from webpack-blocks.

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

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

from webpack-blocks.

Well, less work for us... 🙈🙈

Thx for pointing out!

from webpack-blocks.

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)

from webpack-blocks.