cssnext-loader

cssnext-loader copied to clipboard

css-loader handle import + url() as require cssnext can handle import & will soon be able to handle url() has well (ref https://github.com/cssnext/cssnext/issues/57) what do you think about handling url() like css-loader ?

Meanwhile, since loaders are executed from right to left, the example should show style-loader, cssnext-loader then css-loader (so import + url() are done at the same time to avoid this kind of issues: https://github.com/webpack/css-loader/issues/33 or https://github.com/webpack/css-loader/issues/34)

Or maybe, we should just disable import by default overhere so one module handle all of that. But that's not the best thing to do to benefit of shared variables :/

postcss-url has been included in cssnext core (not released yet), but we might use that to make cssnext-loader a replacement for css-loader.

I would love for cssnext-loader to support running url() through webpack loaders, right now postcss-url custom url handler doesn't provide enough info to replicate what url-loader does.

If I get some time in the next week or two I'll try to put together a pull request.

What would you need in the url callback to do what you want ? I can update postcss-url ;)

If the url custom function got not just the url, but also the file path of the containing style sheet, then it should be fairly straightforward to run it through loaders, or at least replicate what you would do with loaders. The custom function would also need to allow for async.

Right now custom functions can't even resolve relative paths since they only get the url.

I think it would be good for cssnext-loader to allow the url option to specify the loaders to use. Something like:

url: {
  url: 'inline',
  loaders: [
    { test:/\.(jpe?g|png)$/i, loader:'img?minimize' }
  ]
}

The loaders would probably need to end without converting to javascript though, which is probably why we couldn't just use the loaders in the main modules config. What do you think?

Also note that putting the css-loader to the right of cssnext-loader doesn't work properly because css-loader outputs javascript, which cssnext won't know how to handle.

I can add an argument to the postcss callback: the postcss node itself. It contains a source property that contains filename (that is what is used by this plugin to rebase (default behavior)).

What we should do instead a doing a loaderception is to call webpack api in this callback, so normal loaders are used (I think css-loader is doing that).

That sounds simpler for the user. My only concern is trying to make sense of the resource. css-loader can handle js because its final output is js.

If cssnext-loader outputs js, you can't pipe it to url-loader.

I guess we could evaluate the module. I dunno I'll try some things and see.

We don't need a url-loader. css-loader handle css to js + url() + @import. with cssnext-loader we can handle url + imports (imports are already handled)

I spent some time trying to pass the urls through the webpack loaders and didn't have any luck getting it to work. I think for now, just getting the postcss node in the custom url handler will help a lot, even if using loaders doesn't work out.

postcss-url 2.1.0 now offer 2 arguments. The one added is the related postcss declaration object. It contains a .source property that might help (=> decl.source.input.filename).