This change was a bit trial and error and might contain issues.
Best to do a thorough review and question everything that looks weird or is unexpected.

⚠️ This is a breaking change for this plugin but it does make it spec compliant (or that is the intention)

In the context of postcss-preset-env there should be a moment where we can ship unaltered css to user agents, so it is important to fix spec issues imho.

RuleExit -> Rule

Processing rules outside in (used to be inside out) ensures that the parent is always fully resolved and doesn't contain any nesting itself.

This was needed as we now optionally wrap the parent selector in :is() to support :

• body > h1, body p { & span {} } -> :is(body > h1, body p) span {}

If the parent selector contains nesting it would not be valid after wrapping in :is() :

• & h1, & h2 { & span {} } -> :is(& h1, & h2) span {} (does not start with &)

First pass to split up and sanitise rules

The spec doesn't allow declarations after nesting :
https://www.w3.org/TR/css-nesting-1/#mixing

article {
  color: green;
  & { color: blue; }
  color: red; /* invalid */
}

This is easy to handle on its own before expanding nested css.

• clone the rule before itself
• for clone : strip all rule and at-rule nodes
• for clone : strip all nodes after a rule or at-rule was encountered
• for node : strip all nodes that aren't of type rule or at-rule

⚠️ Are there cases or syntax where this would remove things that should stay?

Rule within rule detect change :

- node.selectors.every((selector) => selector.trim().lastIndexOf('&') === 0 && validSelector.test(selector))
+ node.selectors.every((selector) => selector.trim().indexOf('&') === 0 && selector.indexOf('|') === -1))

⚠️ I might be wrong about this bit

A rule within rule selector is a valid if & is the first character and when it is a list if every selector in the list starts with &.

No other restrictions seem to exist.

A special provision for | exists. If | is encountered the rule is skipped.
This does not appear to be part of the spec. But this case existed before.

Nest rule within rule detect change :

- comma(node.params).every((selector) => selector.split('&').length >= 2 && validSelector.test(selector))
+ comma(node.params).every((selector) => selector.split('&').length >= 2 && selector.indexOf('|') === -1))

⚠️ I might be wrong about this bit

A nest rule within rule selector is a valid if & exists and when it is a list if every selector in the list has &.

No other restrictions seem to exist.

A special provision for | exists. If | is encountered the rule is skipped.
This does not appear to be part of the spec. But this case existed before.

Merge selectors change :

This is highly opinionated but I try to avoid .reduce() (actually banned it in our org).
It results in code that is difficult to grasp, difficult to refactor and prone to bugs.

• no more .reduce()
• parts of the child selectors are now wrapped in :is() when inserting the parent would alter or break the selector.
• parent selectors are now wrapped in :is() when it is a list of selectors.

These regexp's are used to wrap the child selectors :

/&((?:[\w-_|])(?:[^\s,{]*))/g

/([\w-_|]+)(?:&)/g

Tested with examples like these :

foo &foo foo & baz
&foo{
&foo,&baz {
&foo:is(.foo)
.foo&
.foo& .baz &

⚠️ There might be cases I overlooked, best to verify this.

test/direct.expect.css

This file has a lot of changes because we now wrap with :is().
The code is a bit too dense for me to be sure that all changes are correct and that no bugs were introduced here.