Add regression test for jsxImportSource in non-module files - #64575
Mudassir Mohammed (pmudassir) wants to merge 2 commits into
Conversation
Script files (no imports or exports) used to report TS2875 and TS7026 when using an implicit JSX runtime, even with the runtime package installed, because the implicit `jsx-runtime` import was only synthesized for module files. That was fixed by microsoft/typescript-go#3803, but no test covered this scenario directly. This test checks that a script file resolves the runtime's JSX namespace the same way a module does. Fixes microsoft#64438 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EYwZBkWeDkrW6qUbWvkRMg
Add test for JSX import source resolution in script files
|
Mudassir Mohammed (@pmudassir) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused test and its baselines correctly cover the previously untested script-file behavior.
Review effort: Balanced
Findings: None
What changed in this PR
Adds regression coverage ensuring jsxImportSource resolves correctly in script and module files.
Changes:
- Adds a compiler test with a mock SolidJS JSX runtime.
- Verifies identical diagnostics, symbols, and inferred types.
| File | Description |
|---|---|
tsc/testdata/tests/cases/compiler/jsxImportSourceScriptFile.tsx |
Defines the regression scenario. |
tsc/testdata/baselines/reference/compiler/jsxImportSourceScriptFile.types |
Records inferred types. |
tsc/testdata/baselines/reference/compiler/jsxImportSourceScriptFile.symbols |
Records resolved symbols. |
tsc/testdata/baselines/reference/compiler/jsxImportSourceScriptFile.errors.txt |
Records expected intrinsic-element errors. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Fixes #64438
The bug in #64438 is already fixed on
mainby microsoft/typescript-go#3803. This PR only adds a regression test, because #3803 didn't include one for this scenario.Analysis
Up to TypeScript 6.0, the program only created the implicit
<source>/jsx-runtimeimport for module files (isExternalModule(file) || isolatedModules). The checker, though, always tried to resolve it. So in a script file the checker asked for a resolution that had never been done, and reported TS2875 followed by TS7026, even with the runtime package installed. That's why addingexport {}made the errors go away.microsoft/typescript-go#3803 removed that module-only condition (
tsc/internal/compiler/fileloader.go). The repro from the issue type-checks cleanly in 7.0.2 and still fails in 6.0.3. Since that change, a TS2875 in a script file means the runtime package really can't be found, the same as in a module.Test
jsxImportSourceScriptFile.tsxputs the same JSX in a script file and in a module, with a stub@solidjs/webruntime innode_modules, and expects identical results for both. The<span />line checks that the runtime'sJSX.IntrinsicElementsis actually used, rather than the types falling back toany. Against the commit before #3803, the script file reports TS7026 on every tag instead.I ran
npx hereby validateandnpx hereby check:format.#64445 is also open for this issue and changes the TS2875 wording. This PR only adds a test and doesn't overlap with it.
I used Claude Code (an AI coding agent) to investigate this and write the test. I've reviewed the change and will respond to review feedback myself.