Add note about postcss-nesting and postcss-nested

[yoriiis]

The PR propose to add a note about the incompatibility between postcss-nesting (includes with postcss-preset-env and potentially enables by default) and postcss-nested.

---

postcss-preset-env with postcss-nested can lead to invalid CSS generated. Since postcss-preset-env@7.8.0 the postcss-nesting seems to be enabled by default.

Prerequisites:

• With stage: 2 you have to disable nesting-rules.
• With stage: 4 there is currently no issue as nesting is still experimental, but I strongly recommend disabling nesting-rules to avoid an issue when the feature becomes stable.

Explanations

postcss.config.js

module.exports = {
  plugins: [
    [
      "postcss-preset-env",
      {
        stage: 2,
        features: {
          // "nesting-rules": false // Needs to be disabled
        },
      },
    ],
    "postcss-nested",
  ],
};

Example of invalid CSS

Input

.header {
    &-title {
        color: #000;
    }
}

Output

-title.header {
    color: #000;
}

[romainmenke]

Hi @yoriiis,
Thank you for reaching out about this.

I don't think we should document this.
We can not reasonably document every incompatibility with every other PostCSS plugin.

---

Can you try this config :

module.exports = {
  plugins: [
    "postcss-nested",
    [
      "postcss-preset-env",
      {
        stage: 2,
        features: {
          // "nesting-rules": false // Needs to be disabled
        },
      },
    ],
  ],
};

In general you should first de-sugar and then polyfill or generate fallbacks.
The polyfill and fallback related PostCSS plugins will always expect de-sugared CSS.

Adding a note about this (if it doesn't exist yet) seems reasonable to me.

[yoriiis]

Helo @romainmenke, thanks for your response.

I don't think we should document this.
We can not reasonably document every incompatibility with every other PostCSS plugin.

I understand. At least now there is a trace related to this problem :)

---

Moving postcss-nested before postcss-preset-env works, but we didn't choose that option because an unintended move could be problematic. We preferred to disable the postcss-nesting, it seems to me more suitable for the conflict.

However, I was not aware of your explanation and I think that the move is complementary!
Thanks for the clarification about the plugin execution order.

[romainmenke]

@yoriiis can you take a look at this proposed change :

• https://github.com/csstools/postcss-plugins/blob/document-plugin-order--generous-bonobo-7a65afc7ef/plugin-packs/postcss-preset-env/README.md#position-in-your-postcss-config-list
• https://github.com/csstools/postcss-plugins/pull/1024/files

Would this have helped you with you issue?

[yoriiis]

Would this have helped you with you issue?

About the order of plugins, I think it's good to add.

This rule seems very general imo (like the webpack loaders order), should it be stated in the PostCSS documentation instead? Mentioning it in postcss-preset-env might be fine too

[romainmenke]

Documented more elaborately here : #1024

Thank you again for reaching out about this issue and for opening a pull request.
Although this pull request did not get merged, I did add you as a co-author on #1024