Document outputStyle is set to compressed in production mode

[thibaudcolas]

Documentation Is:

• Missing
• Needed
• Confusing
• Not Sure?

Please Explain in Detail...

There is no documentation that the plugin configures Sass differently in development and production mode: setting the outputStyle to compressed in production, expanded in development.

This is very unexpected for me and I was going to file this behavior as a bug but reading through #763 it seems to be intentional. This should be documented, so people who want to have the exact same output in both modes know how to configure sass-loader.

Your Proposal for Changes

Either have a section about "production optimisations" mentioning this, or mention this where outputStyle is documented.

---

This is very problematic for us because we’ve otherwise configured our styles to compile the exact same way in production and development (same as #763 (comment)). In this case, we noticed the discrepancy because we use PostCSS processing alongside Sass, and this processing can have incorrect handling of whitespace.

See for example:

• Incorrect parsing of calc operations without spaces in parentheses TrySound/postcss-value-parser#86
• Incorrect parsing of theme functions within calc operations without spaces tailwindlabs/tailwindcss#11027
• Cannot parse calculations without spaces around the * operator shellscape/postcss-values-parser#138

[alexander-akait]

Yeah, PR welcome

[thibaudcolas]

@alexander-akait 👍 what do you prefer between a "production optimisations" section and mentioning this alongside existing references to outputStyle?

For what it’s worth here are all the diffs this has caused for us between production and development styles, because of how Tailwind and cssnano process the Sass output differently based on outputStyle.

prod/dev build diffs with outputStyle set by sass-loader

 .w-body-text-large {
   font-size: 1.1875rem;
-}
-.w-body-text,
-.w-body-text-large {
   font-weight: 400;
   line-height: 1.5;
 }
 .w-body-text {
   font-size: 1rem;
+  font-weight: 400;
+  line-height: 1.5;
 }
[…]
  .w-panel__header {
-    margin-inline-start: calc((2 * 1.5rem + var(--header-gap)) * -1);
+    margin-inline-start: calc(
+      (2 * theme('spacing.6') + var(--header-gap)) * -1
+    );
  }
 […]
 .w-panel__heading {
   color: var(--w-color-text-label);
+  cursor: pointer;
 }
-.w-panel__heading,
 .w-panel__heading label {
   cursor: pointer;
 }
[…]
 .w-header {
-  color: var(--w-color-text-label);
   margin-bottom: 2rem;
 }
+.w-header,
 .w-header h1,
 .w-header h2 {
-  margin: 0;
+  color: var(--w-color-text-label);
 }
 .w-header h1,
 .w-header h2 {
-  color: var(--w-color-text-label);
+  margin: 0;
 }
 .w-header h1 {
+  color: var(--w-color-text-label);
   font-size: 1.875rem;

[alexander-akait]

@alexander-akait +1 what do you prefer between a "production optimisations" section and mentioning this alongside existing references to outputStyle?

We can put this infromation to two places:

1. https://github.com/webpack-contrib/sass-loader#getting-started, developer shoud know about before reading (so that this thought is stored in the head throughout the reading)
2. And here https://github.com/webpack-contrib/sass-loader#sassoptions

For what it’s worth here are all the diffs this has caused for us between production and development styles, because of how Tailwind and cssnano process the Sass output differently based on outputStyle.

It should be same... in your diff I see how cssnano combine some rules (it is fine), but calc is broken, is it tailwind issue?

[thibaudcolas]

👍 thank you, I’ll get on with it. Yes as far as I can tell the cssnano differences are fine and the calc is only broken due to Tailwind (probably due to its dependency on postcss-value-parser).

Still I wasn’t expecting this since we use cssnano in development and production to reduce the risk of CSS processing bugs. But as long as there is documentation in sass-loader it seems ok to me.