refactor: manage loader resolution with webpack #287
Conversation
Instead of assuming that child-loaders are the same as the parent, use Webpack’s build in dependency resolution. The benefits of this is that it’s easier to treat the CSS dependency tree differently (i.e. extract text for certain vendor libs). The tradeoff is that it gives people the ability to shoot themselves in the foot if they misconfigure their loaders. This is worthwhile IMHO as the error will fail fast. It shouldn’t change behavior for existing users.
Current coverage is 98.50% (diff: 100%)
|
|
So if you've only got one loader matching all your CSS files, this will have no impact, right? |
|
That's correct. On Thu, Jun 23, 2016 at 6:23 PM Glen Maddern notifications@github.com
|
|
Could we go forward with this pull request? @sokra ? |
|
Currently this doesn't work for the common case where you match But we will probably have a better experience with webpack 2 here. For the webpack 2 and the next version of css-loader we can recommend this ruleset: rules: [
{ test: /\.css$/, rules: [
{ issuer: /\.js$/, use: "style-loader" },
{ use: "css-loader" }
] },
{ test: /\.sass$/, rules: [
{ issuer: /\.js$/, use: "style-loader" },
{ use: ["css-loader", "sass-loader"] }
] }
]With this rules you can even |
michael-ciniawsky
changed the title
|
Fixes #286 |
|
Closed due to inactivity, feel free to reopen :) |
Enables the behavior detailed in #286.
Instead of assuming that child-loaders are the same as the parent, use Webpack’s build in dependency resolution. The benefits of this is that it’s easier to treat the CSS dependency tree differently (i.e. extract
text for certain vendor libs). The tradeoff is that it gives people the ability to shoot themselves in the foot if they misconfigure their loaders. This is worthwhile IMHO as the error will fail fast.
It shouldn’t change behavior for existing users.