ref(typescript): Default to node16 module/moduleResolution by mydea · Pull Request #21520 · getsentry/sentry-javascript

… imports

Svelte's `exports` map does not declare deep subpaths like
`svelte/types/compiler/preprocess`, which our source imports (still needed
for Svelte 3 support). `node16` resolution honors the `exports` map and
rejects these, so pin the svelte package back to the legacy `node` resolver,
which resolves them via filesystem lookup. Emitted `.d.ts` is unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

`@sentry/angular` is `"type": "module"`, so under the new `node16` base
resolution its relative imports would require explicit `.js` extensions
(TS2835), breaking the `ng build`. Like our other framework packages
(react, vue) it's compiled via a bundler (ng-packagr), so set
`module: esnext` + `moduleResolution: bundler` explicitly.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

`@sentry/solid` imports ESM-only deps (`solid-js`, `solid-js/web`). Under the
new `node16` base resolution, a CommonJS file can't `require` an ESM module
(TS1479/TS1541). Like our other framework packages it's bundled, so set
`module: esnext` + `moduleResolution: bundler` explicitly. Emitted `.d.ts` is
unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

`@sentry/angular` is built with ng-packagr, which pins TypeScript 4.6 — that
version predates `node16` and rejects the literal anywhere in the inherited
config chain, even when the package overrides module/moduleResolution. So
stop extending the shared base entirely and inline the effective base options
here, using `esnext`/`node` (which TS 4.6 supports). Build output verified
byte-identical to before.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ests

The TS 3.8 compatibility job patches the base tsconfig before running, but
only stripped `noUncheckedIndexedAccess`. With the base now defaulting to
`node16` module/moduleResolution (added in TS 4.7), TS 3.8 fails on the
unrecognized literal. Downgrade both to TS 3.8-compatible `esnext`/`node` in
the `use-ts-3_8.js` setup scripts for node and node-core integration tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The previous attempt set `module: esnext` when patching the base tsconfig for
TS 3.8. But the integration-test scenarios run via `node -r ts-node/register`,
so ts-node compiled them to ESM and they crashed on load as CommonJS — every
scenario timed out. Restore the pre-`node16` base shape instead: drop `module`
(ts-node falls back to CommonJS, as before) and keep `moduleResolution: node`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>