Closed justafish closed 3 years ago
Sorry, I completely burned out.
You will need to send a PR to fix it (it will be not easy to make this PR, but pretty possible in a week or two). I will help you with PR, feel free to ask questions.
Sorry to hear that, I hope you're getting the rest you need :purple_heart:
I don't know much about PostCSS plugins, but I'll try! :smile:
I setup this CSS file:
.section {
color: red;
&__top {
color: blue;
}
}
When I step through with the debugger, these are the matches I see -
Plugin | Processor | Matched rule |
---|---|---|
autoreset | Rule | .section |
autoreset | Rule | &__top |
nested | RuleExit | &__top |
nested | RuleExit | .section |
nested | RuleExit | .section |
autoreset | Rule | .section__top |
nested | RuleExit | .section__top |
and then finally, OnceExit
in autoreset has gathered [.section, &__top, .section__top]
So, looking at https://postcss.org/api/#processors I'm guessing this is the order in which processors are run? If so does this issue happen because postcss-nested
uses RuleExit and that will always run after Rule
no matter what order the plugins are in? (My example has postcss-nested
first.
Yeap, the problem that postcss-autoreset
see old removed CSS rules. I think it will be better to change postcss-autoreset
and collect all selector in root.walkRules
in OnceExit
to avoid collecting removed rules.
I am using https://github.com/maximkoretskiy/postcss-autoreset and given an input such as
I should get
However the output from postcss-autoreset is giving me something like -
It seems that the
Rule
processor in postcss-autoreset is receiving both&__top
and.section__top
as a selector, as if the nested version of the rule wasn't removed from the tree. This doesn't happen in 5.0.1 of postcss-nested.