fix(typescript): apply plugin defaults after parsing tsconfig files, honoring extension#2004
fix(typescript): apply plugin defaults after parsing tsconfig files, honoring extension#2004newswim wants to merge 2 commits into
Conversation
|
@newswim thanks for the PR, but there's a ton of clanker fluff in your PR description. please distill that down. I'd also be interested in seeing the prompt(s) you used to generate this PR. |
| @@ -1,5 +1,13 @@ | |||
| # @rollup/plugin-typescript ChangeLog | |||
|
|
|||
| ## v12.3.1 | |||
There was a problem hiding this comment.
CHANGELOGS should never be manually changed. This is one of those AI-generated PR time waster gripes that maintainers have. Please be more diligent in checking the contents before submitting PRs.
There was a problem hiding this comment.
Will do. The frustration is understandable, apologies
@shellscape Fair feedback, and I can. For context, I used Claude Code when implementing the fix, but bug surfaced in the wild inside of my team's monorepo. I've been using a workaround in the meantime and wanted to try to get this behavior patched upstream. As for sharing the prompt, happy to share the design doc if it'd be useful — it has local filesystem paths I'd just want to scrub first. I have a repro that has more information and a more robust test suite: |
newswim
force-pushed
the
fix/ts-plugin-defaults-respect-extends
branch
from
98ec0e5 to
ce01801
Compare
…s wins
DEFAULT_COMPILER_OPTIONS were spread into the leaf tsconfig's compilerOptions slot
passed to ts.parseJsonConfigFileContent, which TypeScript treats as values set
directly on the leaf. That meant the plugin's module: 'esnext' default silently
overrode anything inherited via extends, producing TS5110 under TypeScript 5.x
when a base config set module/moduleResolution to nodenext.
Apply defaults after parseJsonConfigFileContent returns, only for keys the
resolved config left unset. ts.convertCompilerOptionsFromJson coerces JSON
strings ('esnext') to the parsed enum form (ts.ModuleKind.ESNext).
Adds an extends-nodenext fixture plus a version-independent unit test on
parseTypescriptConfig and an end-to-end TS5110 check. Two pre-existing tests
that relied on the buggy default-override behavior now pass module: 'esnext'
explicitly. fakeTypescript helper picks up a convertCompilerOptionsFromJson
stub.
resolves rollup#1726
resolves rollup#1583
newswim
force-pushed
the
fix/ts-plugin-defaults-respect-extends
branch
from
ce01801 to
2dadbe2
Compare
newswim
changed the title
3 participants
Rollup Plugin Name:
typescriptThis PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
resolves #1726
resolves #1583
Description
The util function
parseTypescriptConfigspreadsDEFAULT_COMPILER_OPTIONSintocompilerOptions, which is passed tots.parseJsonConfigFileContent. So the plugin defaults win over anything inherited viaextends, which in turn triggers TS5110 when usingtypescript@5.x.The current state requires that users restate
module/moduleResolution: nodenextin the rollup config in order to not be forced into default values ({ module: 'esnext', skipLibCheck: true }). This is tenable for small projects, but cumbersome in large monorepos.The fix
Apply defaults after
parseJsonConfigFileContentreturns, only for keys the resolved config left unset.ts.convertCompilerOptionsFromJsonhandles the JSON→enum coercion.Tests
extends-nodenextfixtureparseTypescriptConfig(version-independent, red on master) and one end-to-end TS5110 check.module: 'esnext'explicitly;fakeTypescripthelper gets aconvertCompilerOptionsFromJsonstub.With the patch, tests pass on TS 4.8.4 (bundled) and TS 5.9.3