Do not terminate a hack-prefixed property before a comment - #2126

PostCSS aims for byte-to-byte equal output, but since 8.5.22 the stringifier invents a semicolon in a declaration list:

postcss.parse('a{*--x:red/*c*/}').toString()
// => 'a{*--x:red;/*c*/}'   (8.5.21 and earlier: unchanged)

_--x behaves the same. The output stays valid CSS and re-parses to the same AST, so nothing breaks downstream — but a tool that only means to touch what it edits now emits an unrelated ;.

Why

The parser decides whether a declaration is a custom property from the first token of the declaration:

let customProperty = start[1].startsWith('--')   // lib/parser.js, other()

#2117 re-derived that decision in the stringifier from prop:

child.type === 'decl' && child.prop.startsWith('--')

Those two agree almost always, but decl() strips the */_ hack prefix out of prop and into raws.before after the parser has made its choice:

if (node.prop[0] === '_' || node.prop[0] === '*') {
  node.raws.before += node.prop[0]
  node.prop = node.prop.slice(1)
}

So *--x:red is parsed as a normal declaration — its value stops at the first comment, and the comment is already a separate node — while the stringifier sees prop === '--x' and terminates it. The semicolon #2117 adds is there to stop a custom property's value from swallowing a following comment; here there is nothing to protect, because *--x:red will not re-parse as a custom property either. The same mismatch happens whenever anything but spaces precedes the property, since decl() collects those tokens into before too (a{'s'--x:1/*c*/}).

Fix

Check before alongside prop, so the stringifier asks the same question the parser did — will this re-parse as a custom property? — and terminates only the declarations that need it.

Tests

• keeps hack-prefixed property before a comment unchanged — *--x / _--x round-trip byte-for-byte, and still re-parse to decl,comment.
• terminates indented custom property followed by a comment — a whitespace-only before is still a custom property and still gets its semicolon, so the narrowing can't be over-read as before === ''.

The two tests from #2115/#2117 pass unchanged. pnpm unit is 683/683, types and size-limit pass, and lint is clean apart from the pre-existing RootExit sort warning on main.

I also re-ran a round-trip check over ~320k generated stylesheets (parse(css).toString() === css, plus AST-shape stability across a re-parse) at both root level and nested in a rule/at-rule: every failure it reported was this one cause, and after the change it reports none.