feat: Migrate to TypeScript 6.0.3 (prepare for 7)

[ovr]

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Description of Changes Made

Bumps typescript from ~5.2.2 to ~6.0.3 in all 43 packages that pin it (cubejs-client-ngx stays on ~5.4.5, pinned by Angular 18) and clears the tsconfig options TypeScript 6.0 turns into hard errors: moduleResolution: node and baseUrl are gone in favour of module/moduleResolution: nodenext, types: ["*"] restores the previous @types/* auto-include now that the default is [], and rootDir is stated explicitly where TS 6 requires it (TS5011). Two packages need a different mode — cubejs-schema-compiler uses moduleResolution: bundler with module: commonjs because antlr4's .d.cts re-exports .d.ts files that are ESM under its own type: module (TS2834, so antlr4 resolves to nothing), and the bundled client-react/playground use bundler too. Because nodenext emits import() verbatim instead of downlevelling it, the two live dynamic-import sites (container.ts loading the user's cube.js, getDriver.ts) are back on require — jest cannot execute a native dynamic import in its CJS VM, an absolute-path ESM import is fatal on Windows, and a native import would put the whole CommonJS module on .default. The remaining source changes are a handful of root causes rather than a long tail (getEnv's Parameters<Vars[T]> alone accounted for 1592 of the 2074 initial errors), @typescript-eslint moves to ^8 with eslint ^8.57.1 and @stylistic/eslint-plugin-ts for the four rules v8 dropped, and cubejs-testing moves to the end of the root reference list because TS 6 keeps a failed module resolution in the cache shared across tsc --build, which broke materialize/crate/redshift on cold builds only.

Verified with a clean yarn tsc, yarn build, yarn lint, packages/cubejs-playground yarn build:lib and per-package yarn unit; the only failures are pre-existing (schema-compiler error-reporter, raw-time-dimension-timezone, client-vue3) or environmental locally (backend-native port conflict, sqlite3 native binding).

🤖 Generated with Claude Code

[claude]

Claude finished @ovr's task in 2m 17s —— View job

---

Re-review of the rebase onto v1.7.35 — no new authored content, no new findings. Rebase is clean; 3 prior threads still apply.

Full review — what actually changed, verification, and thread status

• Establish what changed since the last reviewed state
• Verify the rebase against master's new base (v1.7.35 version bumps)
• Re-check the migration's own invariants across the tree
• Check the one new root-level structural addition for Docker safety
• Resolve stale threads / dedupe against prior comments
• Post review

Scope

This synchronize is a force-push with no new authored content. The merge base moved from 61f1fa5 (lerna 10) to c93da32 v1.7.35, the lerna release commit that bumps every workspace package to 1.7.35. The 19 commits are the same 19 by title, and their author dates all predate my last review — the newest, 389b650 fix(build): run driver jest suites with --experimental-vm-modules, is dated 2026-09-07 16:29 +0200, i.e. the commit I reviewed as af36f03. So what's genuinely new to review is the interaction between this PR and the release bump.

Verified — the rebase itself

• The one version-bearing line the PR owns was carried correctly. ebd8f3c swapped materialize's devDep, and the rebase landed it at the new release version rather than leaving a stale pin: the diff against master is exactly -"@cubejs-backend/testing": "1.7.35" → +"@cubejs-backend/testing-shared": "1.7.35", and packages/cubejs-testing-shared/package.json:3 really is 1.7.35. No other 1.7.3x literal appears anywhere in the PR's packages/*/package.json delta, which is what a correct rebase of a toolchain bump onto a release commit should look like — the PR touches ranges (typescript, @types/*, @typescript-eslint/*) and lerna touches versions, so the two edits are disjoint everywhere else.
• No conflict residue. No <<<<<<</>>>>>>> markers in any .json/.ts/.js in the tree.
• The pin is uniform at the new base: 43 typescript: ~6.0.3 across packages/* + rust/* + root, and exactly one ~5.4.5 (cubejs-client-ngx, as documented). No ~5.2.2 remnant.
• No TS 6-invalid option reached the tree from master. Re-swept every tsconfig*.json: the only files still carrying baseUrl or moduleResolution: "node" are packages/cubejs-client-ngx (deliberately on 5.4.5) and packages/cubejs-playground/vizard (separate package.json/lockfile, pins its own typescript, built via cd ./vizard && yarn build). Both correctly out of scope, and the release commit added no new workspace package needing coverage.
• lerna 10 survived: root dependencies still has "lerna": "^10.0.1", untouched by the PR's devDependencies edits.
• The new root reference is Docker-safe. tsconfig.json's only delta against master is { "path": "packages/cubejs-testing/cypress" }, and neither image copies the root tsconfig.json — both Dockerfiles copy only tsconfig.base.json (dev.Dockerfile:32, testing-drivers.Dockerfile:29) and build via yarn lerna run build, i.e. per-package tsc following each package's own references. Root yarn build is lerna run build:client-core && tsc --build packages/cubejs-client-react && rollup -c, which never reads the root project list either. So adding a project that points at a directory neither image copies cannot reintroduce the TS6053 class of failure that 4b0a6f5 fixed — that failure lived in the per-package reference graph, which is unchanged here.
• yarn clean still covers the new project's emit (packages/cubejs-testing/cypress/{tsconfig.tsbuildinfo,dist}), which the packages/*/{…} glob would have missed.

Findings

None. Nothing in this push changes code, config values, or the build graph relative to the state I reviewed — the delta is entirely a new merge base.

Comments

No comment changes in this push, and none needed.

Prior threads

Three remain unresolved and still applicable. I re-read all three files in the rebased tree and none is addressed: MemberLabelText.tsx:6 is still ComponentType<Props>, getDriver.ts:13 still hand-rolls driverModule.__esModule ? driverModule.default : driverModule, and packages/cubejs-databricks-jdbc-driver/package.json:22 is still "unit-tests": "jest dist/test --forceExit" with no --experimental-vm-modules.

Thread	Status
databricks-jdbc unit-tests — the one suite that reaches the lazy import() didn't get the flag	Untouched (sharpest of the three)
testing-drivers/getDriver.ts:13 — third divergent hand-rolled interop	Untouched
MemberLabelText.tsx:6 — ComponentType<Props> erases prop typing	Untouched

Nothing became stale, so nothing to resolve, and no duplicate inline comments posted. The force-push marked several already-resolved threads outdated; I left those alone.

Not checked

No node_modules in this job, so no yarn tsc / yarn build / yarn lint. Because the previous head's objects aren't fetchable here, "no new authored content" rests on the commit titles plus author dates rather than a tree-level diff against af36f03 — if any of those commits was amended rather than merely replayed, I would not have seen it. The rebase-quality checks above are the part I verified directly against the working tree. CI on the new base is the authority on the build claim.

· · branch migrate-typescript-6-0-3 ·

[claude]

Claude finished @ovr's task in 53s —— View job

---

Re-review of 1c7e929 — suggestion applied verbatim; no new findings. 1 thread resolved, 2 prior still apply.

Full review — scope, verification, and thread status

• Diff the new commit against the previously reviewed state
• Verify the flag reaches the suite that needs it
• Re-check that no other suite reaches the lazy loads
• Resolve stale threads / dedupe against prior comments
• Post review

Scope

1c7e929 is the only new commit and it's a one-line change: NODE_OPTIONS=--experimental-vm-modules on packages/cubejs-databricks-jdbc-driver's unit-tests script. That's exactly the finding from my last review, applied as suggested.

Verified

• It's the right script. "test": "npm run unit-tests" delegates to it, so both entry points inherit the flag; unit-tests is the only jest invocation in that package.json.
• It's still the only suite that needs it. Re-swept every test file in packages/ for .unload( — packages/cubejs-databricks-jdbc-driver/test/DatabricksDriver.test.ts (lines 68, 78, 108, 123) remains the sole hit, and it's the only place BaseDriver's await import('./storage-fs/*.fs.js') is evaluated under jest's CJS runtime. The flag is now on all six packages that plausibly touch a dynamic import (base-driver, athena, clickhouse, prestodb, databricks-jdbc, testing-drivers); the other four remain belt-and-braces rather than load-bearing, which is harmless.
• The .js-stripping mapper still applies here. packages/cubejs-databricks-jdbc-driver/jest.config.js spreads ../../jest.base.config, so moduleNameMapper's ^(\.{1,2}/.*)\.js$ is inherited; jest dist/test resolves the relative storage-fs specifiers inside base-driver's dist either way, since that tree has no .ts siblings.

The one thing this commit doesn't change, and can't: push.yml:137 runs lerna run unit, and this script is named unit-tests, so it still isn't in the CI matrix. Pre-existing and out of scope for a toolchain bump — flagging it only so it's clear the fix is verified by reading, not by a green job.

Findings

None. Nothing else in the tree changed.

Comments

No comment changes in this commit, and none needed — if someone strips the flag the error names itself (A dynamic import callback was invoked without --experimental-vm-modules), and the reasoning lives in the commit message.

Prior threads

Thread	Status
databricks-jdbc unit-tests — the one suite that reaches the lazy import() lacked the flag	Resolved — this commit
testing-drivers/getDriver.ts:13 — third divergent hand-rolled interop	Untouched
MemberLabelText.tsx:6 — ComponentType<Props> erases prop typing	Untouched

No duplicate inline comments posted, and no new ones needed.

Not checked

No node_modules in this job, so no yarn tsc and no jest run — the commit message's claim that the databricks suite now passes is taken at face value, and the sweep above is from reading the tree. CI is the authority on the build.

· · branch migrate-typescript-6-0-3 ·