fix(compiler): adopt jsx and lib from the project's tsconfig in ts7 - #196
Open
techfreaque wants to merge 2 commits into
Open
fix(compiler): adopt jsx and lib from the project's tsconfig in ts7#196techfreaque wants to merge 2 commits into
techfreaque wants to merge 2 commits into
Conversation
Contributor
|
@mabr-pcvisit is attempting to deploy a commit to the Vercel Labs Team on Vercel. A member of the Team first needs to authorize it. |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
Both bugs share one root cause: the ts7 tsconfig-adoption mechanism in adoptProjectConfig7() only lets a fixed allowlist of options through, forcing everything else — including jsx and lib — to scriptc's own defaults with no override. jsx wasn't adopted at all, so any .tsx file failed type-checking with tsgo's "--jsx is not set" even when the project's tsconfig.json sets jsx. Worse, jsx also wasn't handled by serializeOptions()'s enum-to- string switch (which converts TypeScript's numeric enum-valued compiler options back to tsconfig string form), so naively adopting it crashed with "unhandled enum-valued compiler option 'jsx'" instead of just failing to type-check. lib was unconditionally FORCED to ["lib.es2025.d.ts"] with no way to widen it, so a project whose tsconfig sets "lib": ["ES2025", "DOM"] could never get DOM globals into scope, even for code reachable only through type-only imports. Fix: move the lib default from FORCED_OPTIONS (never overridable) to BASE_OPTIONS (overridden by adopted config), adopt jsx/jsxImportSource/ lib from the project's tsconfig when set, and add the missing jsx case to serializeOptions()'s enum-reverse-mapping switch.
techfreaque
force-pushed
the
fix-ts7-jsx-lib-adoption
branch
from
August 22, 2026 09:29
92384f1 to
7e81976
Compare
vercel[bot]'s review caught that the hardcoded jsx string table used TypeScript 5.9.3's JsxEmit ordering (React=2/ReactNative=3), but 7.0.2 renumbers it (ReactNative=2/React=3) - silently swapping "react" and "react-native". Verified against the real dist/enums/jsxEmit.js module. Fixed properly rather than just correcting the numbers: JsxEmit now goes through the same loadHiddenEnum + enumKeyOf symbolic reverse- mapping as ModuleResolutionKind/ModuleDetectionKind, so no numeric enum value is ever hardcoded in this file again (matching enums.ts's own stated invariant). Only the enum-key-name -> tsconfig-spelling step (ReactNative -> "react-native", etc.) stays a fixed table, since that's a spelling convention, not a value that could renumber.
techfreaque
force-pushed
the
fix-ts7-jsx-lib-adoption
branch
from
August 22, 2026 10:10
090905a to
763ed24
Compare
techfreaque
added a commit
to techfreaque/scriptc
that referenced
this pull request
Aug 22, 2026
# Conflicts: # packages/compiler/src/frontend/program.ts
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
1 participant
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.
Problem
Two related bugs in the ts7 (tsgo) tsconfig-adoption path in
packages/compiler/src/frontend/program.ts.jsx crashes instead of being unsupported.
jsxisn't in the adopted-options allowlist, so any.tsxfile fails type-checking with tsgo's--jsx is not seteven when the project's owntsconfig.jsonsets"jsx": "react-jsx". Worse, naively addingjsxto the adopted set alone crashes the whole compile, becauseserializeOptions()inpackages/compiler/src/frontend/ts7/program.tshas a hardcoded switch that converts TypeScript's numeric enum-valued compiler options (target/module/moduleResolution/moduleDetection/lib) back to their string spelling for the synthesized in-memory tsconfig, and throws for any numeric option it doesn't recognize:lib is unconditionally forced, with no override.
libis forced to["lib.es2025.d.ts"]inFORCED_OPTIONS(by design not overridable by adoption) regardless of what the realtsconfig.jsonspecifies. A project whosetsconfig.jsonsets"lib": ["ES2025", "DOM"]has no way to get DOM globals into the checked program.Root cause
adoptProjectConfig7()merges options as{ ...BASE_OPTIONS, ...adopted, ...FORCED_OPTIONS }— anything inFORCED_OPTIONSalways wins, and anything not in theADOPTED_OPTIONSallowlist is silently dropped.jsxwas in neither the allowlist norserializeOptions()'s enum switch;libwas inFORCED_OPTIONS, which can never be overridden.Fix
libdefault fromFORCED_OPTIONStoBASE_OPTIONS, so it still applies when a project sets nothing, but is now overridable by adoption.adoptProjectConfig7(), adoptjsx,jsxImportSource, andlibfrom the project's parsed tsconfig when present.jsxcase toserializeOptions()'s enum-reverse-mapping switch (TypeScript'sJsxEmitenum: None/Preserve/React/ReactNative/ReactJSX/ReactJSXDev), mirroring the existing target/module/moduleResolution/moduleDetection/lib cases.Verification
cd packages/compiler && node node_modules/typescript5/bin/tsc -p tsconfig.json— 0 errors.packages/compiler/test/ts7/program.test.ts,order-parity.test.ts, andresolver-parity.test.tssuites via vitest; no new failures introduced by this change (pre-existing failures on this Windows environment are path-separator related and reproduce identically on unmodifiedmain)..tsxfixture (jsx: "react-jsx",lib: ["es2025", "dom"]in a synthesized tsconfig) compiled throughloadProgram/checkPreflight: the previous crash (unhandled enum-valued compiler option 'jsx') is gone, and the checker instead reports ordinary, expected type diagnostics (missing@types/react, resolved DOM globals), confirming both options are now correctly adopted end to end.