Overriding default config for file-loader and url-loader

[viktor-nikolaev]

I have a question. This configuration for my .less files

module.exports = createConfig([
setContext(stylesDirectory),
entryPoint({
    "style-day-mode": "style-day-mode",
    "style-night-mode": "style-night-mode"
}),
setOutput({
    path: helpers.root("./wwwroot/styles"),
    filename: "[name].js"
}),
addPlugins([
    new webpack.NoErrorsPlugin(),
    new webpack.optimize.OccurenceOrderPlugin(true),
    new ExtractTextPlugin("[name].css", {allChunks: true})
]),
customConfig({
    resolve: {
        extensions: ["", ".less"],
        modulesDirectories: ["node_modules", stylesDirectory]
    },
    module: {
        loaders: [
            {
                test: /\.less$/,
                loader: ExtractTextPlugin.extract("css!less")
            },
            {
                test: /\.(eot|svg|ttf|woff|woff2)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
                include: /node_modules/,
                loader: "file-loader?name=../fonts/[name].[ext]"
            },
            {
                test: /\.(gif|png)$/,
                include: /ReportWriter/,
                loader: "url-loader?name=../images/[name].[ext]&limit=10240"
            }
        ]
    },
})
]);

however it's conflicting with default @webpack-blocks config created in createBaseConfig.
Is there any way to override the behavior?

[andywer]

Hey @Veikedo.

That's a rather tricky one. If it's really the default config it is conflicting with we could do the following:

You could try monkey-patching the node_modules/@webpack-blocks/webpack/index.js file to see if that solves your issue:

Before:

function createConfig (configSetters) {
  return core.createConfig(webpack, [ createBaseConfig ].concat(configSetters))
}

After:

function createConfig (configSetters) {
  return core.createConfig(webpack, configSetters)
}

We could provide a createConfig.vanilla() method that does the same with the next release (I was going to release today anyway, because of another change).

Could you try that and confirm that it works?

@eXon I always feared that this default config might cause trouble one day, but hoped it was so generic that it would be ok... What do you think about createConfig.vanilla()?

[viktor-nikolaev]

Hi @andywer
yes, monkey patching solves the issue. I just commented the default loaders in createBaseConfig function.
on the image is what the conflict does. url-loader ignores the limit I set in my config, and file-loader ignores the path where I store assets

[viktor-nikolaev]

btw as far as you are going to release, could you please add text/x-less to defaultFileTypes.js? so I can use yours great extractTextPlugin without modifications

[andywer]

Sure :)

I don't know if you need the less-loader more than once and if you would like to contribute code, but it would certainly be cool if you would open a PR introducing a Less block 😊

[andywer]

Please try @webpack-blocks/webpack@0.4.0-rc.1 and use createConfig.vanilla() instead of createConfig().

Keeping it open until you confirm that it works for you 😉

[viktor-nikolaev]

@andywer thank you!

However you could not just omit resolve.extensions, without it the build fails with an error in webpack's core. So the function should be something like that

function createVanillaConfig (configSetters) {
  function initial() {
    return {
        resolve: {
            extensions: [ '']
        }
    }
  };

  return core.createConfig(webpack, [ initial ].concat(configSetters))
}

[andywer]

@Veikedo Thanks for the quick feedback! Now the question is... How vanilla should the "vanilla config" be... 😅

1. If you opt-in for the vanilla config this is now your thing to care about.
2. Vanilla config providing default resolve.extensions is still ok

I think I've got to sleep a night about that...
@eXon Any thoughts?

[viktor-nikolaev]

@andywer here is my workaround for that moment

const monkeyPath = () => ({
    resolve: {
        extensions: ['']
    }
});

module.exports = createConfig.vanilla([
    monkeyPath,
....

without the patch it fails as in the picture

[viktor-nikolaev]

interesting that moving my customConfig (which has resolve.extensions) at the top does not solve the issue

[andywer]

interesting that moving my customConfig (which has resolve.extensions) at the top does not solve the issue

That seems odd! Are you sure there is not another problem? (Maybe compare the two generated configs)

resolve: { extensions: [ '' ] }

Ahhh... I didn't recognize that setting resolve.extensions to [''] already fixes the issue 😉

[andywer]

PS: Does an empty array as resolve.extensions work, too?

[viktor-nikolaev]

@andywer no it does not. At least empty extension must be present

[andywer]

Yeah, I read the resolve.extensions documentation and I think the whole problem boils down to:

If you configure any kind of custom resolve.extensions webpack will drop the default extensions and just use the ones you pass. And the empty string is by default not part of the resolve.extensions. I assume you import/require files using their extension (require('./foo.js') as opposed to require('./foo')), that's why you cannot just stick to the webpack defaults (setting no resolve.extensions at all).

Bottom line: I think the vanilla config should really be vanilla (that means no resolve.extensions either), because otherwise we might need to add another really-vanilla config in future. I suggest you use the vanilla config and set the resolve.extensions manually for now, but resolve.extensions including '' should become part of #60 :)

Does that sound ok to you?

[viktor-nikolaev]

@andywer I just found that extract-text block assumes that module.loaders section exists (see this line). So it fails when using current implementation of createVanillaConfig.

I understand your concerns. However, in my opinion there is nothing bad in providing a skeleton of webpack.config, ie with empty resolve.extensions, empty loaders section and so on.

Also an empty extension '' is included by default in webpack2

[andywer]

I just found that extract-text block assumes that module.loaders section exists (see this line). So it fails when using current implementation of createVanillaConfig.

Good point! There is nothing wrong with providing an empty loaders array I think. Will change that, thanks :)

I understand your concerns. However, in my opinion there is nothing bad in providing a skeleton of webpack.config, ie with empty resolve.extensions, empty loaders section and so on.

The problem is that an empty resolve.extensions will also disable webpack's default extensions. I would agree if setting an empty array would not change webpack's behavior there...

Also an empty extension '' is included by default in webpack2

Ahh. Ok, then they did not update the docs yet...

[viktor-nikolaev]

Ahh. Ok, then they did not update the docs yet...

@andywer it's in the migrating guide https://webpack.js.org/guides/migrating/#resolve-extensions

[andywer]

@Veikedo Can you confirm that adding an empty module.loaders array fixes the problem (like in #95)? I would close the issue if that works.

Or do you need me to publish another 0.4.0-rc* version?

[viktor-nikolaev]

@andywer unfortunately can't check till next week. I think, it should work fine

[andywer]

@Veikedo Any news? 😉

[viktor-nikolaev]

@andywer oh, sorry. Yes, everything is working.
Thank you!

[andywer]

Awesome! :)