fix(formatter): resolve pending space in fits measurer before expanded-mode early exit

[Dunqing]

Closes #20519
Alternative to #20858

Summary

The fits() measurer in the printer defers Space elements via a pending_space boolean flag. When the measurer exits early through an expanded-mode line break (Fits::Yes), any unresolved pending_space is silently lost — causing the measured width to be off by one.

This caused the decorator in @property(...) prop: Type to incorrectly stay on the same line because the space after : was not counted in the width measurement.

Root cause

In FitsMeasurer::fits_element, Space sets pending_space = true (deferred), while HardSpace immediately increments line_width. When fits() returns Fits::Yes via the expanded-mode line break path (line 1040), the pending space is never resolved.

For the decorator case:

1. After @property(...) + space + tooltipPlacement + : → line_width = 80
2. Space after : → pending_space = true (line_width stays 80)
3. Union type group inherits Expanded mode → if_group_breaks(separator) included
4. Separator's SoftOrSpace in Expanded mode → return Fits::Yes without resolving pending_space
5. The +1 char from the space is lost, making the decorator group incorrectly "fit"

Fix

Resolve pending_space before returning Fits::Yes from the expanded-mode early exit path. This matches Ruff's approach where Space is counted eagerly via fits_text(Text::Token(" ")).

Conformance

• JS: 746/753 (unchanged)
• TS: 591/601 (unchanged — 18148.ts fixed, comment.ts regressed)

The comment.ts regression (typescript/union/consistent-with-flow/comment.ts) is a pre-existing Prettier bug — at printWidth: 81, Prettier itself produces the same double-indented output with a spurious blank line:

// printWidth: 81 → Prettier also double-indents:
type SuperLong...Blaa =
                         ← spurious blank line
    | Fooo1000           ← 4 spaces (double indent)

At exactly 80 chars, Prettier avoids this only because its own fits check has the same off-by-one (the space is not counted), causing the Fluid layout's inner group to accidentally "fit".

Test plan

• cargo test -p oxc_formatter — 262 passed
• cargo test -p oxc_formatter -- fixtures — 213 passed (including new issue-20519.ts)
• cargo run -p oxc_prettier_conformance — JS 746/753, TS 591/601
• cargo clippy -p oxc_formatter — clean

🤖 Generated with Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 44 untouched benchmarks
⏩ 7 skipped benchmarks¹

---

_{Comparing fix/printer-fits-pending-space (a6aa1d4) with main (ca79960)²}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (2ac7527) during the generation of this report, so ca79960 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[leaysgur]

The fix itself LGTM, thanks!

BTW, May I ask:

1. Why do we need pending_space at all?
2. Is HardSpace still needed?

Asked Claude and got answer like:

• 1: Ruff resolves Space immediately via fits_text(Text::Token(" ")) / print_text(Text::Token(" ")), which eliminates this entire class of bugs (missed resolution on early-return paths).
  • I looked into whether there's a technical reason oxc can't do the same, but couldn't find one — trim_trailing_ascii_whitespace() is already called at line breaks regardless, so the deferred approach doesn't save anything
• 2: It doesn't exist in Ruff too and its current implementation seems inconsistent
  • In the Printer, it's handled identically to Space (pending_space = true), but in FitsMeasurer it does an immediate line_width += 1 without resolving pending_indent
  • If we switched to ruff's immediate-resolution approach, both Space and HardSpace could just call fits_text(" ") / print_text(" "), removing the inconsistency and the need for a separate element

[Dunqing]

The fix itself LGTM, thanks!

BTW, May I ask:

1. Why do we need pending_space at all?
2. Is HardSpace still needed?

Asked Claude and got answer like:

• 1: Ruff resolves Space immediately via fits_text(Text::Token(" ")) / print_text(Text::Token(" ")), which eliminates this entire class of bugs (missed resolution on early-return paths).

  • I looked into whether there's a technical reason oxc can't do the same, but couldn't find one — trim_trailing_ascii_whitespace() is already called at line breaks regardless, so the deferred approach doesn't save anything

• 2: It doesn't exist in Ruff too and its current implementation seems inconsistent

  • In the Printer, it's handled identically to Space (pending_space = true), but in FitsMeasurer it does an immediate line_width += 1 without resolving pending_indent
  • If we switched to ruff's immediate-resolution approach, both Space and HardSpace could just call fits_text(" ") / print_text(" "), removing the inconsistency and the need for a separate element

Some related issues/PRs in Prettier require a pending space to solve.

• Fix the union type that contains an extra empty line prettier/prettier#18197
• Incorrectly calculated line width prettier/prettier#18148

In the early days, I found a few bugs in Prettier, but that doesn't happen in Biome. I think Biome has noticed these bugs and taken a different approach.

I am not sure why Ruff doesn't need pending_space (maybe this is not a JavaScript/TypeScript formatter??). I think you should look into Biome instead because the implementation came from that, and Ruff is also a fork of Biome.

It's fine to follow Ruff if no tests fail, and removing HardSpace is acceptable since it is of no use and can be done immediately; that will help us avoid walking in the wrong direction quickly.

[Dunqing]

Merge activity

• Apr 2, 8:31 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Apr 2, 8:31 AM UTC: Dunqing added this pull request to the Graphite merge queue.
• Apr 2, 8:35 AM UTC: Merged by the Graphite merge queue.

[leaysgur]

It's fine to follow Ruff if no tests fail, and removing HardSpace is acceptable since it is of no use and can be done immediately; that will help us avoid walking in the wrong direction quickly.

Yes, that's exactly the point. I want to avoid having to decide "which one to use?" in the future.

I'll look into deleting it. 💪🏻