With version 7.3.0 of sass-loader, compression is also done during the production build process. Apparently, this happens before autoprefixing kicks in (postcss-loader), which causes the necessary grid comments (/* autoprefixer grid: on */) to be removed, thus preventing Grid autoprefixing for IE during production.
I have found 2 possible fixes:
/*! autoprefixer grid: on */enableSassLoader(function (options) { options.outputStyle = 'expanded'; })Personally, the 2nd fix seems to be the best solution, but maybe this can be provided by default when compression is already done by postcss-loader?
Indeed - because CSS minification is handled with mini-css-extract-plugin, I can't think of any reason for us to want Sass to do this for us. So I also vote for option (2) - specifically, making the outputStyle nested by default (because I think this is the default setting in dev?). @wimhendrikx would you be able to create a PR for this? The relevant file should be https://github.com/symfony/webpack-encore/blob/master/lib/loaders/sass.js
Indeed - because CSS minification is handled with mini-css-extract-plugin, I can't think of any reason for us to want Sass to do this for us
People can opt-out from using the mini-css-extract-plugin, so that's a (small) breaking change. Not a big issue though since they would still be able to change options.outputStyle when calling Encore.enableSassLoader().
specifically, making the outputStyle nested by default (because I think this is the default setting in dev?)
That point may cause a bigger issue though, because Dart Sass does not seem to support nested: https://sass-lang.com/documentation/js-api#outputstyle
- "expanded" (the default for Dart Sass) writes each selector and declaration on its own line.
- "compressed" removes as many extra characters as possible, and writes the entire stylesheet on a single line.
- "nested" (the default for Node Sass, not supported by Dart Sass) indents CSS rules to match the nesting of the Sass source.
- compact (not supported by Dart Sass) puts each CSS rule on its own single line.
We'll have to be careful about setting options that are not directly handled by the loader since they are passed to the chosen implementation which may or may not support them.
I've created a PR #639. Any remarks are welcome!
Any reason for this issue not being closed?
@garak I think we simply forgot to close it since most of the time it's done automatically thanks to the fix/close/... keywords.
It should be OK with the latest version of Encore, if that's not the case feel free to reopen.