explicit requires should override loader pattern

[geddski]

Shouldn't explicit loaders override the webpack config?

For example if my webpack config has a pattern for loading all html files with one loader:

{ test: /\.html$/, loader: "ngtemplate"}

// this works
var template = require('mytemplate.html');

But if somewhere in the app the html file is loaded explicitly with a different loader:

var template = require('text!mytemplate.html');

The result is now the output of the ngtemplate loader, instead of the plain text of the file. Is this a bug?

[sokra]

var template = require('!text!mytemplate.html');

[denis-sokolov]

Thanks, @sokra! This information is useful and was notably missing from the documentation. I have updated the documentation, let me know if I’m mistaken.

And it seems like the issue may be closed now. @geddski, does the answer cover your use case?

[geddski]

the leading ! didn't really work for my case, because while migrating Domo to webpack I had to keep things backwards compatible with requirejs for a time. I found another way to do what I needed. But I agree that this info is very useful. But I still think the local require is more specific and should override the loader patterns without the extra !. Seems a more sensible default IMO.

[silvenon]

If you chain loaders like this:

loaders: [{
  test: /\.s?css$/,
  loader: 'style!css'
}, {
  test: /\.scss$/,
  loader: 'sass'
}]

your SCSS files will be compiled with style!css!sass, so adding different behavior to the require() call could be confusing. I would rather that the leading ! feature was added to configuration as well:

loaders: [{
  test: /\.s?css$/,
  loader: 'style!css'
}, {
  test: /\.scss$/,
  loader: '!style!css!postcss!sass'
}]

because this doesn't work 😕

[jamesmfriedman]

@geddski, found this trying to fix the same problem. Ended up working for me.

[Delagen]

@sokra I have loader before typescript that replace in source path to html with require call with !raw-loader but it still use file-loader that is defined in global config.

[saawsan]

@sokra answer works perfectly. Thanks.

However, I think it's worth mentioning that ESLint forbid the use of inline loaders. I had to rule this config out.
https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-webpack-loader-syntax.md

[gejgalis]

I confirm the issue. I wanted to override configuration with inline require('raw-loader!./foo.tpl'), but webpack is still processing my configuration with test: /\.tpl$/

I thought I could have 2 separate configurations:

1. test: /\.tpl\?raw$/, loader: 'raw-loader'
2. test: /\.tpl$/, loader: 'vue-template-loader'

and use it by:

1. require('./foo.tpl?raw')
2. require('./foo.tpl')

but unfortunally webpack drops everything after file path before executing the tests :(

I can't migrate to webpack 2 due to this issue... :(

[sberney]

Yeah, I can't realistically use !raw-loader!./path-to-file.html in place of raw-loader!./path-to-file.html, because the code generated by my webpack project will be loaded by runtime things like requirejs and systemjs. They don't support !raw-loader! syntax.

I also think that raw-loader!./path-to-file.html ought to override the default plugin configuration.

[silvenon]

Could you give more details about your setup? Why does your project contain webpack-specific loader paths if they aren't being consumed by webpack?

That behavior is not a bug, so introducing such a breaking change to webpack would have big consequences.

[vankop]

Answer above #1747 (comment)

Closing because of inactivity

[sberney]

I still don't understand why it doesn't work the way I expected (and the way other bundlers work), but I am not having this problem anymore. Like others, part of the problem was legacy code used in transition for years. Unlike others, I'm never going to fully transition to an entirely webpack-based runtime. I want to partially compile the requires, and partially "pre-compile" them so that requirejs and other programs can finish the job.

I realize now that webpack needs more than the band-aid implied by fixing this to support the workflow I want in the places I want it. I have off-and-on thought about building my own tooling to perform the specifics tasks of preparing files to be consumed by the specific types of things I am using (like requirejs and systemjs) at runtime.