ref(build): Switch TypeScript moduleResolution to bundler#21559
Merged
Conversation
Changes the shared base tsconfig from `moduleResolution: "node"` to `"bundler"` (supported since TS 5.0, no TypeScript upgrade required). `bundler` resolution respects package `exports` maps, so deep imports into non-exported subpaths no longer resolve. - Replace the deep `svelte/types/compiler*` type imports with `svelte/compiler` and a small set of vendored preprocessor types. - Inline `@sentry/angular`'s `tsconfig.ngc.json` so it no longer extends the shared base config — ng-packagr ships an older TypeScript that rejects `"moduleResolution": "bundler"` when parsing the extends chain. - Downgrade `bundler` back to `node` in the TS 3.8 compat scripts, since TS 3.8 predates the `bundler` option.
logaretm
requested review from
JPeer264,
mydea,
nicohrubec and
s1gr1d
and removed request for
a team
JPeer264
approved these changes
Jun 16, 2026
| // older TypeScript that doesn't support "moduleResolution": "bundler". | ||
| { | ||
| "extends": "./tsconfig.json", | ||
| "include": ["**/*.ts", "src/**/*"], |
Member
There was a problem hiding this comment.
This is sad that we have to do this :(
But it seems to be the only way
Member
Author
There was a problem hiding this comment.
Yea, I don't want to go on an upgrade trip and find the lowest possible version of angular build tooling that both works for us and makes the angular SDK build properly without breaking our support range.
We probably need to upgrade this setup at somepoint.
Member
|
Missing from #21520, which we should IMHO also pull into this PR, are:
|
Addresses review feedback: now that the shared base tsconfig defaults to `moduleResolution: "bundler"`, the per-package resolution overrides are unnecessary. moduleResolution only affects how we author/type-check the code, not what consumers receive, and we build everything with bundlers. - Drop redundant `moduleResolution: "bundler"` overrides that just duplicate the base default. - Drop the `Node16` overrides (node, node-core, tanstackstart, and the nextjs/remix test configs) so they inherit `bundler`. Where `module` was set to `Node16` for dynamic imports / top-level await, switch it to `esnext` (compatible with `bundler` and still supports both). - Remove redundant `lib: ["es2020"]` entries that match the base. - Add `packages/typescript/**` to nx.json's shared named inputs so changes to the base tsconfig bust the build cache. `angular/tsconfig.ngc.json` (ng-packagr's older TS), `astro/tsconfig.dev.json` (ts-node runtime) and browser-integration-tests (internal `@sentry/core/src` deep imports) intentionally keep their `node`/`node16` resolution.
Only node-core actually uses dynamic `import()` (which requires a `module` of es2020+); node and tanstackstart have none, so they can inherit the base default. Emitted declarations are unchanged.
Pair the base `moduleResolution: "bundler"` with an explicit `module: "esnext"` (the canonical bundler pairing — tsc requires a modern ESM `module` with `bundler`, and only `esnext`/`bundler` or `node16`/`node16` are valid combinations). Previously the base left `module` unset, so it defaulted to `es2015`, which predates dynamic `import()` and top-level await. That forced ~25 packages to each declare `module: "esnext"` and was why node-core needed its own override. Setting it once in the base makes all of those redundant, so they're removed. Only `astro/tsconfig.dev.json` keeps an explicit setting (it pins `moduleResolution: "node"` for ts-node). Emitted `.d.ts` output verified byte-identical across all packages.
Setting `module: esnext` + `moduleResolution: bundler` in the base config leaks into ts-node, which then hands `.ts` helper scripts to Node's native ESM loader and fails with `ERR_UNKNOWN_FILE_EXTENSION` (e.g. aws-serverless `buildLambdaExtension.ts`, nextjs `buildRollup.ts`, root `ci-unit-tests.ts`). Add a `ts-node` override in the root tsconfig pinning `module: commonjs` + `moduleResolution: node` for script execution. ts-node merges this key across the `extends` chain, so the single override covers every package and dev-package that extends the root config. Type-checking / `.d.ts` emit are unaffected (they use the top-level compilerOptions).
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
Comment on lines
+96
to
+100
| export interface PreprocessorGroup { | ||
| markup?: MarkupPreprocessor; | ||
| style?: Preprocessor; | ||
| script?: Preprocessor; | ||
| } |
Contributor
There was a problem hiding this comment.
Bug: The vendored PreprocessorGroup type is missing the name property, which is required in Svelte 4 and 5, potentially causing runtime errors in user projects.
Severity: MEDIUM
Suggested Fix
Add the name: string; property to the PreprocessorGroup interface in packages/svelte/src/types.ts. Then, assign a unique name to the preprocessor objects created in packages/svelte/src/preprocessors.ts to conform to the Svelte 4+ API.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/svelte/src/types.ts#L96-L100
Potential issue: The vendored `PreprocessorGroup` type, which is used to configure
Svelte preprocessors, is missing the `name` property. While the project's tests pass
with Svelte 3, the package claims support for Svelte 4 and 5, where this property is
required according to official types and documentation. If a user integrates this SDK
with a Svelte 5 project, the Svelte compiler may throw a runtime error when it receives
a preprocessor object without the expected `name` property, causing the build process to
fail.
Also affects:
packages/svelte/src/preprocessors.ts:1~10
Did we get this right? 👍 / 👎 to inform future reviews.
Member
Author
There was a problem hiding this comment.
Those are internal types, not exposed to users AFAIK.
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.
A couple of notable changes:
nodewhich is deprecated in next releases tobundlerwhich better reflects our own setup.esnextwhich was already being used all over.Some changes were required for
svelteSDK because it imported non-exportable types, I opted to vendor them instead. Also one minor exception is introduced for TypeScript 3.8 because it does not supportbundlermodule resolution strategy.replaces #21520