Remove automatic -loader module name extension

[jhnns]

I'm submitting a feature request

Webpack version:
2.x

Current behavior:
webpack automatically appends -loader to a module when the first module lookup failed

Expected/desired behavior:
webpack should not append -loader

What is the motivation / use case for changing the behavior?
It can lead to errors that are hard to understand for newcomers. I've seen it a couple of times that webpack tried to resolve the css module as css-loader because people have just configured loader: "css". In combination with npm@3, this can be very confusing as you may have never installed the css module by yourself.

This change would probably require a lot of webpack configs to be adjusted, but since the loader configuration has been changed in webpack@2 anyway, we should include that change as well. As a downside, the config will become a little more verbose because now everyone has to write style-loader!css-loader, but I think the benefit outweighs the downside by far.

[TheLarkInn]

This makes sense. Its not too much extra work to have someone add "-loader". Explicit.

[bebraw]

Yeah, this would be a good change for webpack 2. Less confusion.

[amsdamsgram]

Hi, I'm willing to take a look at this if no one is already on it!

[TheLarkInn]

Go right ahead.

[TheLarkInn]

This would however land after webpack 2.x as it would be a pretty irritating breaking change unless anyone disagrees?

[amsdamsgram]

No worries.
Where should I start looking at?

[jhnns]

@iDams awesome! 👍
@TheLarkInn This would be a change that requires a lot of webpack.configs to be adjusted. But: Since we are changing the way how loaders are configured in webpack 2 anyway, we should put this change into webpack 2.x

[amsdamsgram]

Hey, I could use some advice :D
I've started looking into /lib files especially those which seems to be linked to module like ModuleParseHelper.js, RawModule.js, ... Am I in going into the right direction?

[andreypopp]

@iDams see this line https://github.com/webpack/webpack/blob/master/lib/WebpackOptionsDefaulter.js#L93

[amsdamsgram]

@andreypopp thanks!

[amsdamsgram]

So I think removing this line will remove automatic "-loader" but I would like to test it to be sure and also to see if everything still works fine.
How can I test?

I tried to run npm test but there are 7 tests failed and 32 pending on master without any changes yet.
Is it normal?

[jhnns]

If there are already failing tests on master, you can ignore them. Just check if your changes don't break additional tests.

@sokra failing tests on the main branch make contributing a lot harder. We should try to keep failing tests only on feature branches. Have we ever talked about using git flow? :)

[amsdamsgram]

Thanks @jhnns, I will check.

But how can I actually test that webpack doesn't actually add "-loader" to a module name?
Because for now, I am just assuming it won't :/

I tried to run node build.js in examples/code-splitted-css-bundle/ but I got the following error

My goal was to replace css-loader by css in the webpack.config.js file and check that webpack was not adding "-loader" anymore.

[jhnns]

Looks like the example is broken 😁

There are several ways how to test this. I think the easiest way would be to use css in a webpack.config.js and then to check for an error (because just css should not work anymore).

[jhnns]

If you have troubles writing the test, we can also omit I think. Tests should usually check for actual behavior, not for behavior that used to be there.

[sokra]

@iDams you can add a test case in test/configCases for this. Just check if an error is emitted by webpack for resolving (this is possible with a errors.js in the test directory, see other test cases).

[sokra]

In the example the generation of the README fails, because the build fails. Looks fine. You can also run the examples with node ../../bin/webpack.js example.js js/output.js or node ../../bin/webpack.js depending on the example (check if entry and output is in webpack.config.js).

[sokra]

I tried to run npm test but there are 7 tests failed and 32 pending on master without any changes yet.
Is it normal?

no, it should work. Compare your result to the travis build: https://travis-ci.org/webpack/webpack

Check if you done the setup correctly: https://github.com/webpack/webpack/blob/master/CONTRIBUTING.md#setup
The npm link stuff is important.

[amsdamsgram]

@jhnns @sokra Thanks, I will try to add a test in configCases + look why I have errors on master

[amsdamsgram]

Still have failed tests on master with a correct setup

I have done the setup correctly now. Thanks @sokra for pointing the npm link stuff. I didn't do it.
But even on master, when I run npm test, I have 2 failed tests.

Lost of failed tests with my changes

And when I remove this line
I have more errors, and npm test doesn't finish properly.
I get a npm ERR! Test failed..
I have huge errors like this:

All the loaders tests failed with kind of the same error like in
require("raw!...") or require(css!...) etc. I get a can't resolve raw or css

Any input on this?
I will keep looking how this is related to the line I removed!

[jhnns]

Any input on this?
I will keep looking how this is related to the line I removed!

This is exactly why removing this line is a breaking change. You need to adjust the failing test cases, they should use val-loader!... instead of just using val!...

[amsdamsgram]

Got it, thanks!

[amsdamsgram]

Hey, I submitted a PR.

All tests passed on my local but travis-ci on Linux with node.js 5 failed.

Do you have any advice on how to debug this?

I've seen couple of options, VM, Travis Build, Vagrant or with a docker image.
I'm on OSX so I will probably have to install a VM with Linux.

[jhnns]

See #3102 (comment)

[wesleycho]

I would like to add that this was a frustrating breaking change that appears to have fairly weak rationale behind it relative to the cost - having to chase around what changed for an hour and filing PRs to fix Webpack plugin projects was not fun.

[TheLarkInn]

I apologize for the this @wesleycho. This change is one of many steps that plan to pave the way for overall more consistent and standard config usage.

This was something that would have had to been cherry picked out and then back into master if we tried to avoid it. I will create an issue that will block 2.x release until we have a great error message that will help people migration through this change.

Alternatively we would welcome any suggestions for this as well. Catching the 100x ways to specify loaders has made it very hard to catch and consistently error (which is why we don't have a PR merged for this yet).

[sokra]

Here you are: #3289

[simonbuchan]

Hmm, I expected that resolveLoader.moduleExtensions would work the same as resolve.extensions (used to): and try each appended to the request in order. i.e, it defaulted to moduleExtensions: ['-loader', ''] and would try css-loader first, then css

I suspect the breaking-changeness of this could be walked back in a 2.3+ safely enough by making it work that way, which should only break if someone has some-loader-loader but expected to find some-loader exactly - npms.io isn't great at finding module name patterns, but I couldn't see any such names.

With the change to resolve.extensions though, I'm not sure that it still works that way? E.g. try all the extensions first? https://webpack.js.org/configuration/resolve/ isn't clear on what happens with conflicts.

[jcrben]

Next time, I suggest that instead of removing something like this in 2.x, put a warning in 2.x and remove it in 3.x.

[hzlmn]

@jcrben It's the way how @postcss do it. Webpack team should learn more about convenient releases from it.