This fixes #115. It’s a much deeper change than I would have liked, but I see no other way to fix the issue.
In order for tail ampersands (a & {…}) to be replaced correctly, we need to know the parent’s full selector before we can replace the &. Therefore we need to do the replacements on the way down (in Rule) instead of on the way up (in RuleExit).
This has all sorts of implications for plugin execution order. I needed to change how @-rules are handled to make the pre-existing it works with other visitors test pass. Otherwise, the fix for the & rules would have changed the order of rule declarations in the resulting CSS.
All the existing tests still pass (except for one whitespace issue; see the last commit) and I’ve added a bunch more to make sure, but you should probably still consider flagging this fix as a breaking change.
This fixes #115. It’s a much deeper change than I would have liked, but I see no other way to fix the issue.
In order for tail ampersands (
a & {…}
) to be replaced correctly, we need to know the parent’s full selector before we can replace the&
. Therefore we need to do the replacements on the way down (inRule
) instead of on the way up (inRuleExit
).This has all sorts of implications for plugin execution order. I needed to change how @-rules are handled to make the pre-existing
it works with other visitors
test pass. Otherwise, the fix for the&
rules would have changed the order of rule declarations in the resulting CSS.All the existing tests still pass (except for one whitespace issue; see the last commit) and I’ve added a bunch more to make sure, but you should probably still consider flagging this fix as a breaking change.