Repository navigation
fix: improve error message for JSX in non-module files (Issue #64438) - #64616
Open
Om Dandagvhal (OMD-123) wants to merge 1 commit into
Open
Om Dandagvhal (OMD-123) wants to merge 1 commit into
Om Dandagvhal (OMD-123) wants to merge 1 commit into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
…ft#64438) When a file uses JSX but is not an external module (no imports/exports), the error message 'This JSX tag requires the module path X to exist...' is confusing because the file cannot import modules at all. The fix checks if the file is an external module before attempting to resolve the JSX runtime import. If not, it returns nil early, which allows the existing 'JSX element implicitly has type any' error (7026) to surface as the primary diagnostic. This matches the expected behavior described in the issue where the real issue is 'scripts can't import modules'.
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The early return can hide missing runtime imports and disable runtime-provided JSX types, and lacks regression coverage.
Review effort: Balanced
Findings: 1
Improves JSX diagnostics for non-module files by skipping implicit runtime resolution.
Changes:
- Detects source files without an external-module indicator.
- Suppresses JSX runtime resolution for those files.
| File | Description |
|---|---|
| tsc/internal/checker/jsx.go | Adds the non-module early return. |
Sorry, something went wrong.
Comment thread
tsc/internal/checker/jsx.go
Comment on lines
+1455
to
+1457
| // If the file is not an external module (no imports/exports), it cannot import the JSX runtime. | ||
| // Return nil to avoid the confusing "module path ... could not be found" error (Issue #64438). | ||
| if file.ExternalModuleIndicator == nil { |
This branch has not been deployed
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
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
Fixes #64438
The Problem
When a file uses JSX but is not an external module (no imports/exports), TypeScript shows the confusing error:
This is misleading because the file cannot import modules at all - it's a script, not a module. The real issue is that JSX requires the automatic runtime which imports from , but non-module files can't import anything.
The Fix
Added a check in to return early if the file is not an external module (). This allows the existing, more appropriate error (TS7026: "JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists") to surface as the primary diagnostic.
Expected Behavior After Fix
For a file like:
Before: Confusing "module path react/jsx-runtime could not be found" error
After: Clear "JSX element implicitly has type 'any'" error (TS7026) - which correctly indicates the file needs to be a module or have JSX types configured.