Description
Note that I've encountered this in combination with sugarss, which encourages the use of this transform. css-modules uses the :global
and :local
pseudo-selectors to selectively disable/enable css-modules with the selectors nested within.
The following sugarss:
:global .selector
prop: value
another-prop: another-value
Gets transformed into the following CSS:
:global .selector {
prop: value;
another-prop: another-value
}
The previous CSS, after running by postcss-nested-props, is transformed into the following invalid CSS, even though no nested props are present:
: global .selector;
-prop: value;
-another-prop: another-value
It seems to understand :global
as being a nesting of "empty string" with the "global .selector" property name, which... makes very little sense.
Is this intended to support a corner case where the caller specifies a prop value and nested props with the same prop declaration, without any whitespace? Perhaps it would be better to require whitespace before such a construct, specifically to prevent the syntactic ambiguity with pseudo-selectors and pseudo-elements. A regexp whitelist will always be a moving target, and will mysteriously cause breakages every time a new one is used.