[bug][stylelint] rule fails on multiline token fallback values

[zeroedin]

Problem

The rhds/token-values stylelint rule reports a false positive when a token's fallback value is formatted across multiple lines. The rule compares the authored value (with whitespace preserved) against the canonical single-line value from tokens.get(name), so any multiline formatting causes a mismatch.

For example, this is flagged as an error:

color:
  var(--rh-color-text-primary,
    light-dark(
      var(--rh-color-text-primary-on-light, #151515),
      var(--rh-color-text-primary-on-dark, #ffffff)
    )
  );

Even though the value is semantically identical to the single-line form:

color: var(--rh-color-text-primary, light-dark(var(--rh-color-text-primary-on-light, #151515), var(--rh-color-text-primary-on-dark, #ffffff)));

Root cause

In token-values.ts, the comparison at line ~47 uses parser.stringify(values) which preserves authored whitespace (newlines, indentation). The expected value from tokens.get(name) is always single-line. The two never match when the authored CSS is multiline.

Suggested fix

Normalize whitespace before comparing:

function normalizeWhitespace(s: string) {
  return s.replace(/\s+/g, ' ').trim();
}

Then update the comparison:

- if ((expected as string)?.toString() !== actual) {
+ if (normalizeWhitespace((expected as string)?.toString()) !== normalizeWhitespace(actual)) {

The fix() function does not need changes since it already writes the canonical single-line value. With the normalized comparison, fix() will only fire when the actual token value is wrong -- not when only the whitespace formatting differs. This avoids a conflict where fix() collapses multiline values to a single line, which could then trigger a line-length violation.

[bennypowers]

Good idea! I believe there's already in the package lock a library which evaluates the semantic diff of two css expressions. and even if there isn't, we could whip one up. I would prefer semanticallyEquivalent(expected, actual) vs normalizeWhitespace(expected) !== normalizeWhitespace(actual), ifyaknowwhatimean

On a related note, I'm in favour of adjusting our max-len and indent rules to make cem-style doc blocks, light-dark, and variable stacks more ergonomic.

Thanks for opening this @zeroedin , goodonya!

[zeroedin]

Updated suggested fix — the original normalizeWhitespace (collapsing to single spaces) isn't sufficient because postcss-value-parser preserves spaces inside function parentheses (e.g. light-dark( var(...) vs light-dark(var(...)). The comparison should strip all whitespace instead:

function normalizeValue(s: string) {
  return s.replace(/\s+/g, '');
}

Additionally, fix() should guard against rewriting when only whitespace differs. Otherwise it collapses multiline values to a single line, which then conflicts with max-line-length:

  fix() {
+   if (normalizeValue(expected?.toString()) === normalizeValue(actual)) {
+     return;
+   }
    const prefix = node.value.slice(0, parsedNode.sourceIndex);
    let infix = `var(${name}, ${expected})`;
    // ...
  }

This way: the comparison passes for semantically identical values → no report. And as a safety net, fix() won't collapse formatting when the value is correct.

[zeroedin]

I would prefer semanticallyEquivalent(expected, actual) vs normalizeWhitespace(expected) !== normalizeWhitespace(actual), ifyaknowwhatimean

I'll take a look at that approach.