Closed maranomynet closed 1 year ago
How does CSS Nested spec &
on the root or selector-less {}
?
I can't see that it touches on such cases at all.
Then again, this plugin is aiming towards SASS-style nesting, which has very different handling of &
in all sorts of cases.
Gracefully collapsing top-level &
selectors seems like the sensible, unremarkable thing to do.
I prefer throwing an error.
Does Sass throw an error on both & {}
and {}
top levels?
It does.
Can I ask you to add error throwing to this PR? Sorry, I am busy on another open source project.
If this plugin is going to throw on both of these cases I must scramble to refactor some project code before things start breaking.
Let's just close this PR, since all it contains are tests that assert a different (non-throwing) behavior.
I ran into this inconsitent behavior in the plugin.
After thinking about this for a while, I feel that
postcss-nested
ought to handle this gracefully and treat a root-level&
selector token the same way it handles the empty selector — i.e. remove the curly block and replace all instances of&
with the empty string.(For comparison SASSMeister just errors on both of these cases, so... 🤷)
I ran into this in an actual project where we had mixin/function that got (quite reasonably) applied at the root level in certain cases, and the results felt surprisingly unelegant.
I've added these tests, but I'd be thankful if someone could provide/suggest the required changes in
index.js
.