-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove automatic -loader module name extension #2986
Comments
This makes sense. Its not too much extra work to have someone add "-loader". Explicit. |
Yeah, this would be a good change for webpack 2. Less confusion. |
Hi, I'm willing to take a look at this if no one is already on it! |
Go right ahead. |
This would however land after webpack 2.x as it would be a pretty irritating breaking change unless anyone disagrees? |
No worries. |
@iDams awesome! 👍 |
Hey, I could use some advice :D |
@andreypopp thanks! |
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. I tried to run |
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? :) |
Thanks @jhnns, I will check. But how can I actually test that webpack doesn't actually add "-loader" to a module name? I tried to run My goal was to replace |
Looks like the example is broken 😁 There are several ways how to test this. I think the easiest way would be to use |
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. |
@iDams you can add a test case in |
In the example the generation of the README fails, because the build fails. Looks fine. You can also run the examples with |
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 |
Still have failed tests on I have done the setup correctly now. Thanks @sokra for pointing the Lost of failed tests with my changes And when I remove this line All the loaders tests failed with kind of the same error like in Any input on this? |
This is exactly why removing this line is a breaking change. You need to adjust the failing test cases, they should use |
Got it, thanks! |
See #3102 (comment) |
Because it will be required if this change passes: webpack/webpack#2986
Aligns with breaking change introduced with webpack/webpack#3102 See webpack/webpack#2986
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. |
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). |
Here you are: #3289 |
Hmm, I expected that 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 With the change to |
Next time, I suggest that instead of removing something like this in |
Because it will be required if this change passes: webpack/webpack#2986
I'm submitting a feature request
Webpack version:
2.x
Current behavior:
webpack automatically appends
-loader
to a module when the first module lookup failedExpected/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.The text was updated successfully, but these errors were encountered: