`cssnano` not running with postcss-cssnext

[elvingm]

Sometimes when writing nested styles with sugarss some of the postcss plugins that are meant to run with cssnext don't seem to have their intended effect.

#footer
  & .cuervo-links
    & .link
      margin-right: 15px

      & a
        text-decoration: none

Because of this, empty CSS blocks like this #footer .cuervo-links {} end up in the output.
cssnano helps with this which is included in both postcss-cssnext and css-loader, but they don't seem to catch this. I could include cssnano in the plugins, but then I get a duplicate plugin warning.

[jescalan]

Maybe this should be opened in cssnext?

[elvingm]

@Jenius so took a quick look, and cssnext's docs suggests if using webpack that the compress option provided by css-loader should be used. Which in turn uses cssnano under the hood, and which accepts options for each of the postcss modules within it.

cssnano options
It's a somewhat weird little circle I somehow ran in.

[jescalan]

Hmm ok, so ideally we'd have some sort of interface we can use to pass options through to core loaders. I mean you can override them to solve it immediately, but probably would be better to have a cleaner solution.

I'm thinking something like this:

loaderQuery: {
  css: { compress: 'true' }
}

Where the key would just match to the loader name, so possible options at current core would be css, postcss, babel, jade, and file.

Although the jade loader is our work, and accept options through jade directly rather than through a query, so maybe we'd count that one out. I mean another alternative is to just expose each loader's name directly as an option. But some loaders like the postcss one take both query options and direct config options, so that makes things a little messy.

Thoughts?

[elvingm]

I'd side with the idea of passing in options through to the core loaders, if anything (excluding jade).
As far as the messiness of having both query options and direct config options, would it make sense to have it much like your example but instead-

loaderConfig: {
  css: {
    compress: 'true',
    query: { // query options as object here }
  }
}

This way, query options for each loader are within the key there along with its config options, but we omit the object in that query field where we don't need it? Not sure if this is exactly what you're referring to in terms of it getting a little messy

[jescalan]

Ok so I'm taking a closer look at this, and here's how it's broken down:

For css, we run through postcss-loader and css-loader. Both of these loaders take querystring options, and postcss takes config options as well, but we control these and expose them to app.js. So currently, users are not able to set querystring options on either of these loaders.

For html, we use our own custom jade-html-loader, which does not take any querystring options, as is the case with all of our loaders, since they are ugly and incompatible with anything that can't be stringified to JSON. Full options for this loader are exposed through app.js, so users are already fully in control of all options here.

For js, we use just the babel-loader, which takes both querystring and config-attached options and treats them equally. Since we already fully expose config-attached options through app.js, there is no reason to ever use querystring options, so users are fully in control.

So it seems like we just need to expose options for css loader and for the postcss loader. That being said, I would prefer to keep all the postcss options in the postcss config object we already expose, so I think the best approach here is to just take any options that are not handled explicitly through the config, serialize these into querystrings, and pass them through. That leaves us with just the options for css-loader, which we can expose through a new cssLoader configuration option.

Thoughts?