There are two major plugins for nesting in PostCSS that I’m aware of:
- postcss-nested — Do it like Sass
- postcss-nesting — Do it like the spec
There is a lot to unpack here!
I think many people think of PostCSS as a “future syntax CSS processor”, probably due to the ease of setup of using postcss-preset-env, a plugin that is essentially a big group of plugins designed to mimic what of “future CSS” that it can. This is a precedent set by Babel which has worked out pretty well for JavaScript. So indeed, postcss-nesting is the one in postcss-preset-env, and that makes good sense.
One bit of trouble there is that native CSS nesting is fairly turbulent. It’s just been stable enough for Safari and Chrome to ship it in preview browsers, which is not really proof that’s how it will stay.
I think I like how it shipped. It’s easy to learn and teach, as Jen says:
In summary, CSS Nesting will work just like Sass, but with one new rule: you must make sure the nested selector always starts with a symbol.
Along the way, there were all sorts of things considered and tested. Using @nest was a big one. Double {{ }} was considered. Required & was considered. I don’t even know what all was just talked about, what made it into versions of the spec, etc. Looks like postcss-nesting has only been around a few years, but it’s on version 10 already, so it’s undergone plenty of change.
So you could update your packages, and suddenly your CSS won’t compile anymore (or less intense: you start to get compilation warnings) because the way you’ve authored it is no longer what this plugin supports anymore because the spec has changed.
Is that what you want?
There is not a right answer.
That sounds awful to me. I hate that kind of hamster-wheel work of updating code that is no better than how I left it, and maybe worse because I’ve hand-poked it and could have inadvertently screwed it up. But… maybe it’s for the last time. Maybe now the spec is done. Maybe the processor won’t change again because it is mimicking native CSS. Maybe the next time you touch it is removing the processor because you don’t need it anymore. That removal part does sound kind of nice.
The other path, the postcss-nested path, is not beholden to the spec. It’s a nesting spec all to its own which is not intended to ever be removed (like Sass). You don’t wake up to a version change that breaks it because the demands on it aren’t the same, there is no shifting sand under its feet. That sounds nice too. You’re stuck with the tool but it’s stable.
Me, I definitely go with the Sass-like one. More often than not, I’ve added nesting to projects that either had existing SCSS files to migrate or sass-friendly developers who needed convincing to switch to postcss. I’m sure I’ll regret saying this, but I don’t see a non-postcss future and don’t have any interest in a CSS nesting spec. I prefer the configuration of postcss and the format of postcss-nested
Third option: Don’t nest.
I stopped using Scss years ago when I adopted PostCSS and stopped using nesting with it. The potential flaws of nesting are well known I think (sprawling selectors etc) and this post adds another to the pile.
It’s well worth considering whether the advantage of small improvement in DX is worth the potential problems on any given project.
I’m used to the CSS spec version as I’ve been smashing code out with postcss-preset-env for a few years. Luckily the spec version hasn’t changed .
The idea of not nesting doesn’t work for everyone, I personally find it convenient in personal projects. For anyone worried about things going awry when nesting is encouraged, you can establish conventions that can be enforced using StyleLint. For instance, max-nesting-depth.
I have seen nesting cause big problems in large codebases, where I have personally had to refactor code due to how badly nested it was. Again, setting up rules can help mitigate this kind of thing.