Fix expected end offset of a rule with spaces before its own semicolon - #32

Companion to postcss/postcss#2135, which fixes source.end.offset for a rule that owns a stray semicolon preceded by whitespace. That PR's CI is red until this one lands and is released — its only failing test is parses semicolons.css, reading the fixture below.

cases/semicolons.json records the pre-fix value for the a{b:c} ; case added in 8.9.0, and that value is self-contradictory today. In cases/semicolons.css, line 8 is:

a{b:c} ;
@a bbbb;

The rule node's recorded end is:

"end": { "column": 8, "line": 8, "offset": 63 }

• column: 8, line: 8 is the ;, which is at offset 61. end.offset is exclusive, so it must be 62.
• offset 63 is the @ of the next line — it is also the recorded start.offset of the following at-rule node, 30 lines further down in the same file. Two sibling nodes cannot both own byte 63.
• css.slice(54, 63) is "a{b:c} ;\n", while the node's own text is "a{b:c} ;" — the range claims the newline that is the at-rule's raws.before.

So this one number is wrong independently of the parser change; the parser change is just what makes a test notice it.

       "source": {
         "end": {
           "column": 8,
           "line": 8,
-          "offset": 63
+          "offset": 62
         },

Only the a{b:c} ; rule changes. The other ownSemicolon node in the same file, a{b:cc}; on line 7 (ownSemicolon: ";", no space), is already consistent — its ; is at offset 52 and its recorded end.offset is 53 — and is untouched, as is the at-rule's start.offset: 63.

pnpm test passes here (lint + 4 unit tests). This repo's own suite does not re-parse the fixtures, so it is green both before and after; the failure this unblocks is parses semicolons.css in postcss itself.

Precedent for the two-repo sequence: the 8.8 changelog entry is "Update offset according to fix in postcss", and postcss commit be364fd8 bumped this package 8.5.0 → 8.5.1 alongside a parser position fix.

What I did not verify

I have not run any third-party parser that consumes these fixtures (postcss-scss, postcss-less, …) against the new value. They would only be affected if they reproduce the same ownSemicolon arithmetic; I did not check their sources.

Signed-off-by: maximilliangrand 214999687+maximilliangrand@users.noreply.github.com