Skip to content

fix(compiler): preserve HTML entities in JSX text by correctly detecting non-empty lines#717

Closed
everettbu wants to merge 1 commit into
mainfrom
fix/react-compiler-html-entity-preserve
Closed

fix(compiler): preserve HTML entities in JSX text by correctly detecting non-empty lines#717
everettbu wants to merge 1 commit into
mainfrom
fix/react-compiler-html-entity-preserve

Conversation

@everettbu

Copy link
Copy Markdown

Mirror of facebook/react#36050
Original author: MorikawaSouma


@greptile-apps

greptile-apps Bot commented Mar 16, 2026

Copy link
Copy Markdown

Greptile Summary

Mirror of facebook/react#36050. This PR fixes the trimJsxText function's non-empty line detection by replacing the regex lines[i].match(/[^ \t]/) with lines[i].trim().length > 0. The lastNonEmptyLine variable controls whether a space separator is appended between multiline JSX text segments, and an incorrect value could cause HTML entities to be lost or whitespace to be mangled in the compiler's output.

  • Single-line change in trimJsxText() at BuildHIR.ts:3566 improves non-empty line detection for JSX text whitespace trimming
  • The new approach uses trim().length > 0 which has a subtly broader definition of whitespace than the original regex (it includes Unicode whitespace like \u00A0), diverging from Babel's cleanJSXElementLiteralChild reference implementation
  • No new test fixture was added in this PR to cover the specific HTML entity scenario being fixed

Confidence Score: 4/5

  • This PR is safe to merge — it's a minimal, targeted bug fix mirrored from the upstream React repository.
  • Score of 4 reflects that this is a single-line fix from the upstream React repo that addresses a real bug. The behavioral change is correct for common cases. Minor concern about divergence from Babel's reference implementation for exotic Unicode whitespace, but this is an unlikely edge case in practice.
  • No files require special attention — the change is minimal and well-scoped.

Important Files Changed

Filename Overview
compiler/packages/babel-plugin-react-compiler/src/HIR/BuildHIR.ts Single-line fix in trimJsxText replacing regex-based non-empty line detection with trim().length > 0; functionally correct for typical JSX text but subtly differs from Babel's reference implementation for exotic Unicode whitespace characters.

Fix All in Claude Code Fix All in Codex

Prompt To Fix All With AI
This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/HIR/BuildHIR.ts
Line: 3566

Comment:
**Behavioral difference from Babel's reference implementation with `\u00A0`**

This change diverges from the Babel reference implementation (`cleanJSXElementLiteralChild`), which uses `lines[i].match(/[^ \t]/)`. The code comment on line 3557-3558 still references that Babel implementation.

`trim()` removes all Unicode whitespace (including `\u00A0`, `\u2003`, `\uFEFF`, etc.), while the original regex `/[^ \t]/` only considers literal space and tab as "empty" characters. This means a line containing only `\u00A0` (from an ` ` entity) would be detected as "non-empty" by the old regex but "empty" by `trim()`, which could affect `lastNonEmptyLine` and therefore whether a trailing space separator is appended.

In practice this is an unlikely edge case (a line containing *only* ` ` with no other content), but it's worth noting the semantic difference since the comment says this is "adapted from Babel."

How can I resolve this? If you propose a fix, please make it concise.

Last reviewed commit: 8d7d13a


for (let i = 0; i < lines.length; i++) {
if (lines[i].match(/[^ \t]/)) {
if (lines[i].trim().length > 0) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Behavioral difference from Babel's reference implementation with \u00A0

This change diverges from the Babel reference implementation (cleanJSXElementLiteralChild), which uses lines[i].match(/[^ \t]/). The code comment on line 3557-3558 still references that Babel implementation.

trim() removes all Unicode whitespace (including \u00A0, \u2003, \uFEFF, etc.), while the original regex /[^ \t]/ only considers literal space and tab as "empty" characters. This means a line containing only \u00A0 (from an &nbsp; entity) would be detected as "non-empty" by the old regex but "empty" by trim(), which could affect lastNonEmptyLine and therefore whether a trailing space separator is appended.

In practice this is an unlikely edge case (a line containing only &nbsp; with no other content), but it's worth noting the semantic difference since the comment says this is "adapted from Babel."

Prompt To Fix With AI
This is a comment left during a code review.
Path: compiler/packages/babel-plugin-react-compiler/src/HIR/BuildHIR.ts
Line: 3566

Comment:
**Behavioral difference from Babel's reference implementation with `\u00A0`**

This change diverges from the Babel reference implementation (`cleanJSXElementLiteralChild`), which uses `lines[i].match(/[^ \t]/)`. The code comment on line 3557-3558 still references that Babel implementation.

`trim()` removes all Unicode whitespace (including `\u00A0`, `\u2003`, `\uFEFF`, etc.), while the original regex `/[^ \t]/` only considers literal space and tab as "empty" characters. This means a line containing only `\u00A0` (from an `&nbsp;` entity) would be detected as "non-empty" by the old regex but "empty" by `trim()`, which could affect `lastNonEmptyLine` and therefore whether a trailing space separator is appended.

In practice this is an unlikely edge case (a line containing *only* `&nbsp;` with no other content), but it's worth noting the semantic difference since the comment says this is "adapted from Babel."

How can I resolve this? If you propose a fix, please make it concise.

Fix in Claude Code Fix in Codex

@everettbu

Copy link
Copy Markdown
Author

Upstream PR was closed or merged. Code is synced via branch mirror.

@everettbu everettbu closed this Mar 16, 2026
@everettbu
everettbu deleted the fix/react-compiler-html-entity-preserve branch March 16, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants