Support loaders with object based config

[james-s-turner]

Currently multi-loader only supports string based (sub) loaders e.g.

{
      test: /\.txt$/,
      loader: multi ('raw-loader', 'raw-loader'),
}

However the following fails:

 {
      test: /\.txt$/,
      loader: multi({loader: "raw-loader"}, {loader: "raw-loader"})
 }

with the error: Module not found: Error: Can't resolve '[object Object]' As mentioned: this particular example can be fixed using webpack-combine-loaders. However like @delsvr I'm trying to use ExtractTextPlugin to generate stylesheets for multiple themes

 {
      test: /\.scss$/,
      loader: multi(combineLoaders ([
            {loader: ExtractTextPlugin.extract( ... )},
            {loader: ExtractTextPlugin.extract( ... )},
       ]))
 }

This fails because combineLoaders cant transform the returned config into a query string. This is a complete showstopper for me at the moment trying to create multiple themes.

If the multi-loader is not amenable to a solution is there any other way to achieve the desired result?

[albertstill]

Hey @james-s-turner, we're working on the same thing! I have an example repo.

I got ExtractTextPlugin#extract compiling with combineLoaders, because ExtractTextPlugin#extract returns an array of loader configs combineLoaders can stringify.

But the issue is it's not creating the files, maybe ExtractTextPlugin#extract doesn't work with string config notation not sure.

In your example above you can do:

 {
      test: /\.scss$/,
      loader: multi(
          combineLoaders(ExtractTextPlugin.extract( ... )),
          combineLoaders(ExtractTextPlugin.extract( ... ))
      )
 }

[james-s-turner]

Hello @albertstill - good to know it's not just me! Thanks for the tip. Yes I thought I had it cracked too when I got it running without errors, only to have my hopes cruelly dashed when I realised there was no output. Anyway last night I simplified the problem and created my own repo. I've also raised the following issue to get EWTP to work properly when using string based query parameters. TBH I'm not sure which is the best solution fixing EWTP or multi-loader. I was hoping some of the webpack/loader/plugin maintainers would chime in. I think things might be muddied as it look likes ETWP will be superseded by in Webpack 4 by the mini CSS plugin - see issue on ETWP

[james-s-turner]

Hi Again @albertstill - check out updates on the issue about the future of ETWP. ETWP will not support Webpack4 and is being put in "maintenance" mode. Judging by the lack of response on this issue, my EWTP issue and that the maintainers will focus on Webpack4 plugins I think it unlikely this issue will be fixed on webpack3 plugins/loaders. So I opened another issue against the mini-css-extract-plugin. Would be great if you could add your scenario to that issue :-)

[albertstill]

nice work mate, will do!

[albertstill]

Also for the interim at my company I'm just creating multiple Webpack configs each with their own theme, webpack accepts an array of configs.

[Photonios]

The bug is in extract-text-webpack-plugin. When using it with multi and combineLoaders, one ends up with a string based loader, something like this:

node_modules/extract-text-webpack-plugin?id=1&omit=1&remove=true!css-loader!postcss-loader

When this happens, extract-text-webpack-plugin is not extracting text anymore and you don't see any CSS files being emitted. This is because each ExtractTextPlugin instance gets a unique, auto-generated ID. This ID is a sequential integer (starting at 0). The problem is that by stringifying the loader config, the loader receives the ID as a string, which then later causes a comparison to fail. A quick work-around is overriding the auto-generated ID per instance with a random string:

const instance = new ExtracTextPlugin({
       id: 'myinstance',
       filename: ....
});

However, this reveals another bug. The documentation says that the id option is a valid option:

The code also reveals this to be a valid option: https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/master/src/index.js#L32

However, the schema, that is used to validate the options, makes no mention of this field. So when specified, the schema validator complains it's not a valid option. If you manually patch the schema to accept id as valid option, the error goes away and CSS files start being emitted due to working around the initial bug.

https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/master/schema/plugin.json

I've submitted a PR here: https://github.com/webpack-contrib/extract-text-webpack-plugin/pull/774

Feel free to use my fork in the mean time :)

FYI: Combing this fork of multi-loader (https://github.com/sshmyg/multi-loader), combineLoaders and my fixes in extract-text-webpack-plugin made everything work.