[compiler] Restore code frames in ESLint compiler error messages#36901
Merged
Conversation
|
Comparing: 68631c0...beb1164 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
The Rust port (react#36173) changed CompileError events to carry plain serialized detail objects instead of CompilerError class instances. The ESLint integrations previously called detail.printErrorMessage(source, {eslint: true}), which printed the source code frame(s) and location for each error detail. The replacement printErrorMessage() only emitted the reason and description, so code frames were dropped from lint output. Restore the per-detail printing in both ESLint integrations by exporting printCodeFrame from CompilerError and reusing it. The detail loop handles both detail shapes that flow through LoggerEvents: a `details` array (CompilerDiagnostic and the Rust compiler) and a legacy flat `loc` (deprecated CompilerErrorDetail), so it works with the Rust compiler as well as the TypeScript one.
javache
force-pushed
the
fix-compiler-eslint-error-printing
branch
from
June 29, 2026 10:37
dd10828 to
beb1164
Compare
github-actions Bot
pushed a commit
that referenced
this pull request
Jun 30, 2026
) ## Summary The Rust port (#36173) changed `CompileError` `LoggerEvent`s to carry plain serialized detail objects instead of `CompilerError`/`CompilerDiagnostic` class instances. As a result, the ESLint integrations could no longer call `detail.printErrorMessage(source, {eslint: true})` and were given a replacement `printErrorMessage()` helper that only emitted the `reason` and `description`. This regressed error printing: the **source code frame(s) and `file:line:column` location** that used to appear for each error detail were dropped from lint output. This PR restores the previous behaviour: - Export `printCodeFrame` from `CompilerError` and reuse it from both ESLint integrations instead of duplicating it. - Rebuild the full message (reason, description, per-detail code frames, and hints) in `printErrorMessage`. - Handle **both** detail shapes that flow through `LoggerEvent`s: - a `details` array (`CompilerDiagnostic` and the **Rust** compiler), and - a legacy flat `loc` (deprecated `CompilerErrorDetail`). `formatDetailForLogging` emits one or the other, so the previous unconditional iteration over `error.details` would have thrown `TypeError: not iterable` on the flat-`loc` path. Normalizing to a list fixes that and keeps the code working with both the TypeScript and Rust compilers. ## Test plan - `tsc --noEmit` on both ESLint packages is clean (no new errors vs. baseline). - Verified the detail loop handles the Rust compiler's `details` array shape and the legacy flat `loc` shape. DiffTrain build for [9c1f097](9c1f097)
github-actions Bot
pushed a commit
that referenced
this pull request
Jun 30, 2026
) ## Summary The Rust port (#36173) changed `CompileError` `LoggerEvent`s to carry plain serialized detail objects instead of `CompilerError`/`CompilerDiagnostic` class instances. As a result, the ESLint integrations could no longer call `detail.printErrorMessage(source, {eslint: true})` and were given a replacement `printErrorMessage()` helper that only emitted the `reason` and `description`. This regressed error printing: the **source code frame(s) and `file:line:column` location** that used to appear for each error detail were dropped from lint output. This PR restores the previous behaviour: - Export `printCodeFrame` from `CompilerError` and reuse it from both ESLint integrations instead of duplicating it. - Rebuild the full message (reason, description, per-detail code frames, and hints) in `printErrorMessage`. - Handle **both** detail shapes that flow through `LoggerEvent`s: - a `details` array (`CompilerDiagnostic` and the **Rust** compiler), and - a legacy flat `loc` (deprecated `CompilerErrorDetail`). `formatDetailForLogging` emits one or the other, so the previous unconditional iteration over `error.details` would have thrown `TypeError: not iterable` on the flat-`loc` path. Normalizing to a list fixes that and keeps the code working with both the TypeScript and Rust compilers. ## Test plan - `tsc --noEmit` on both ESLint packages is clean (no new errors vs. baseline). - Verified the detail loop handles the Rust compiler's `details` array shape and the legacy flat `loc` shape. DiffTrain build for [9c1f097](9c1f097)
This was referenced Jun 30, 2026
github-actions Bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jul 3, 2026
…ct#36901) ## Summary The Rust port (react#36173) changed `CompileError` `LoggerEvent`s to carry plain serialized detail objects instead of `CompilerError`/`CompilerDiagnostic` class instances. As a result, the ESLint integrations could no longer call `detail.printErrorMessage(source, {eslint: true})` and were given a replacement `printErrorMessage()` helper that only emitted the `reason` and `description`. This regressed error printing: the **source code frame(s) and `file:line:column` location** that used to appear for each error detail were dropped from lint output. This PR restores the previous behaviour: - Export `printCodeFrame` from `CompilerError` and reuse it from both ESLint integrations instead of duplicating it. - Rebuild the full message (reason, description, per-detail code frames, and hints) in `printErrorMessage`. - Handle **both** detail shapes that flow through `LoggerEvent`s: - a `details` array (`CompilerDiagnostic` and the **Rust** compiler), and - a legacy flat `loc` (deprecated `CompilerErrorDetail`). `formatDetailForLogging` emits one or the other, so the previous unconditional iteration over `error.details` would have thrown `TypeError: not iterable` on the flat-`loc` path. Normalizing to a list fixes that and keeps the code working with both the TypeScript and Rust compilers. ## Test plan - `tsc --noEmit` on both ESLint packages is clean (no new errors vs. baseline). - Verified the detail loop handles the Rust compiler's `details` array shape and the legacy flat `loc` shape. DiffTrain build for [9c1f097](react@9c1f097)
github-actions Bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jul 3, 2026
…ct#36901) ## Summary The Rust port (react#36173) changed `CompileError` `LoggerEvent`s to carry plain serialized detail objects instead of `CompilerError`/`CompilerDiagnostic` class instances. As a result, the ESLint integrations could no longer call `detail.printErrorMessage(source, {eslint: true})` and were given a replacement `printErrorMessage()` helper that only emitted the `reason` and `description`. This regressed error printing: the **source code frame(s) and `file:line:column` location** that used to appear for each error detail were dropped from lint output. This PR restores the previous behaviour: - Export `printCodeFrame` from `CompilerError` and reuse it from both ESLint integrations instead of duplicating it. - Rebuild the full message (reason, description, per-detail code frames, and hints) in `printErrorMessage`. - Handle **both** detail shapes that flow through `LoggerEvent`s: - a `details` array (`CompilerDiagnostic` and the **Rust** compiler), and - a legacy flat `loc` (deprecated `CompilerErrorDetail`). `formatDetailForLogging` emits one or the other, so the previous unconditional iteration over `error.details` would have thrown `TypeError: not iterable` on the flat-`loc` path. Normalizing to a list fixes that and keeps the code working with both the TypeScript and Rust compilers. ## Test plan - `tsc --noEmit` on both ESLint packages is clean (no new errors vs. baseline). - Verified the detail loop handles the Rust compiler's `details` array shape and the legacy flat `loc` shape. DiffTrain build for [9c1f097](react@9c1f097)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Rust port (#36173) changed
CompileErrorLoggerEvents to carry plain serialized detail objects instead ofCompilerError/CompilerDiagnosticclass instances. As a result, the ESLint integrations could no longer calldetail.printErrorMessage(source, {eslint: true})and were given a replacementprintErrorMessage()helper that only emitted thereasonanddescription.This regressed error printing: the source code frame(s) and
file:line:columnlocation that used to appear for each error detail were dropped from lint output.This PR restores the previous behaviour:
Export
printCodeFramefromCompilerErrorand reuse it from both ESLint integrations instead of duplicating it.Rebuild the full message (reason, description, per-detail code frames, and hints) in
printErrorMessage.Handle both detail shapes that flow through
LoggerEvents:detailsarray (CompilerDiagnosticand the Rust compiler), andloc(deprecatedCompilerErrorDetail).formatDetailForLoggingemits one or the other, so the previous unconditional iteration overerror.detailswould have thrownTypeError: not iterableon the flat-locpath. Normalizing to a list fixes that and keeps the code working with both the TypeScript and Rust compilers.Test plan
tsc --noEmiton both ESLint packages is clean (no new errors vs. baseline).detailsarray shape and the legacy flatlocshape.