Upgrade to TypeScript 7

[lmorchard]

Context

typescript is currently pinned to ^6.0.3 across all five manifests by #627, after #617 bumped it to ^7.0.2 and broke pnpm run build on main, blocking releases.

This issue tracks doing the TS7 upgrade properly.

Why the pin exists

TypeScript 7.0 (GA 2026-07-08) is the Go port of the compiler — Project Corsa. The relevant consequence is not a bug in any one package:

TypeScript 7.0 does not ship a public programmatic compiler API. Microsoft has said 7.1 will introduce a new — and different — API. Until then, any tool that consumes the TypeScript API programmatically cannot run on TS7.

Visible in the package itself: typescript@6.0.3 ships bin: { tsc, tsserver }; typescript@7.0.2 ships bin: { tsc } only.

The concrete failure we hit:

TypeError: Cannot read properties of undefined (reading 'useCaseSensitiveFileNames')
  at node_modules/.pnpm/rollup-plugin-dts@6.1.1_.../rollup-plugin-dts.cjs
  in tsup/dist/rollup.js

tsup runs declaration emit through rollup-plugin-dts, which reads ts.sys.useCaseSensitiveFileNames from the programmatic API. Under TS7 that API isn't there.

This affects a broad set of ecosystem tools (typescript-eslint, ts-jest, ts-morph, and others), not just us.

What actually blocks us

#	Blocker	Status
1	tsup DTS pass via rollup-plugin-dts	Hard blocker. rollup-plugin-dts@6.4.1 (latest) declares peerDependencies.typescript: ^4.5 || ^5.0 || ^6.0. tsup is already at latest 8.5.1. No upgrade path exists today.
2	ts-json-schema-generator@2.9.0	Not currently blocking — it depends on typescript: ^5.9.3 and resolves its own copy (TS 5.9.3 is in the lockfile alongside the root version), so check:schemas is insulated from the root bump. Worth confirming that stays true.

What is not blocked

The codebase itself already typechecks clean under TS7. Between #617 and #627, main was on ^7.0.2 and every PR's Typecheck core / Typecheck CLI / Typecheck server step passed — the tsc CLI works fine. The blocker is narrowly the programmatic-API consumers in the build pipeline.

So this is a tooling upgrade, not a source-code migration.

What needs to happen

1. Wait for TypeScript 7.1, which is expected to introduce the replacement programmatic API. Historical cadence puts that around October 2026.
2. Wait for rollup-plugin-dts to port to that API, and for tsup to pick up the new version. Track:
   • https://github.com/Swatinem/rollup-plugin-dts
   • https://github.com/egoist/tsup
3. Then bump typescript in all five manifests together — root, packages/cli, packages/core, packages/server, packages/extension. They must move as a unit or scripts/check-dep-versions.mjs fails. (build(deps): pin typescript below 7 to unbreak the release build #627 initially missed extension and server; CI caught it.)
4. Verify against the release path, not just tests. ci: guard the release build on PRs #614 adds a Release build job that runs the root pnpm run build, executes the built binary, and checks tarball completeness. That job is what turns this class of breakage from silent into loud — it's how the TS7 break was found. Confirm it's green before merging any future TS bump.

Alternative worth evaluating

If we want TS7's speed before the API lands, the side-by-side approach used elsewhere in the ecosystem:

• keep typescript at 6.x for the build pipeline
• add @typescript/native-preview (currently 7.0.0-dev.20260707.2, "Preview CLI and JS API for the native TypeScript compiler port") purely for fast typechecking, e.g. a tsgo --noEmit CI step

That gets the ~10x typecheck speedup without touching declaration emit. Worth a spike if CI typecheck time becomes a pain point; not urgent otherwise.

Guardrail in the meantime

Dependabot will keep proposing typescript@7. Options:

• add an ignore entry for typescript major versions in .github/dependabot.yml, or
• rely on ci: guard the release build on PRs #614's Release build job to fail the PR loudly

The second is strictly better than today's silent-merge behaviour, but the first avoids the churn. Doing both is reasonable.

References

• TypeScript 7 is out — the native Go port, what changed, and what to watch
• Why Your TypeScript 7 Upgrade Broke ESLint, ts-jest, and ts-morph
• TypeScript 7.0 Native Compiler: What Breaks, What Gets 10x Faster, and How to Migrate
• rollup-plugin-dts

[lmorchard]

Added the guardrail from the "in the meantime" section: #629 stops Dependabot proposing TypeScript major bumps.

Ignore rules are applied before grouping, so minor and patch updates still flow through the devdependencies group — only majors are suppressed. The ignore block should be removed as part of doing this upgrade, and the comment in dependabot.yml points back here.

[lmorchard]

Correction: rollup-plugin-dts is not a hard blocker

The issue above frames the DTS pipeline as an unavoidable dependency. Having actually tested it, that's wrong, and the correction matters for planning — so recording it here.

The repo already has a TS7-safe declaration path it isn't using. packages/core emits declarations with plain tsc (declaration: true in packages/core/tsconfig.json) — 67 .d.ts files. That's the tsc CLI, not the programmatic API, so it works under TS7. Corroborated by the fact that main ran on TS7 between #617 and #627 and every typecheck job passed.

Only the root build reaches for rollup-plugin-dts, via tsup's dts option, to produce the published dist/core/src/index.d.ts.

Spike

1. Set dts: false in tsup.config.ts → build succeeded, 16s vs ~25s, zero .d.ts emitted
2. Copied core's 67 tsc-emitted .d.ts into dist/core/src/
3. npm pack, installed the tarball into a clean throwaway project
4. Typechecked a consumer mirroring the documented usage in README.md

import { WebAgent, PlaywrightBrowser } from "@tabstack/pilo";
import type { WebAgentOptions, ProviderConfig } from "@tabstack/pilo";

const browser = new PlaywrightBrowser({ headless: true });
const providerConfig: ProviderConfig = { model: "openai/gpt-5.6" };
const agent = new WebAgent(browser, { providerConfig });

Results:

• A deliberately bad line (const bad: number = agent) produced error TS2322: Type 'WebAgent' is not assignable to type 'number' — proving types actually resolve rather than silently degrading to any
• The corrected program above typechecks clean
• The declarations also caught two real errors in my first draft (WebAgent takes 2 arguments; ProviderConfig is { model }, not { provider, model, apiKey })

Why it works

tsup's core entry is packages/core/src/**/*.ts — a mirrored tree, not a single bundle. So dist/core/src/ has the same shape as core's own tsc output, and the NodeNext .js specifiers (export * from "./core.js") resolve against the copied .d.ts identically. Only the CLI entry is genuinely bundled, and bin needs no types.

Caveats before anyone implements this

• declarationMap — core sets it, so its .d.ts end with //# sourceMappingURL=index.d.ts.map. The spike copied only *.d.ts, leaving those references dangling. Either also copy the 67 .d.ts.map (they point at ../src, which isn't in the tarball) or strip the comments.
• Flattening loss — rollup-plugin-dts rolls declarations into fewer files and can inline types; tsc preserves module structure. No functional downside spotted for this package, but it is a real output difference.
• The spike copied files by hand. A real change needs a build step — a tsc --emitDeclarationOnly pass, or a copy in tsup's existing onSuccess hook, which already copies extension artifacts.
• Only the . export was exercised — though that is the entire published surface, so coverage is complete.

Revised picture

Blocker #1 in the table above should read soft, self-imposed rather than hard. Dropping rollup-plugin-dts would remove the TS7 blocker outright and cut ~9s off the build, independent of anything upstream.

Blocker #2 (ts-json-schema-generator, which also consumes the TS API) then becomes the next thing to check. It currently resolves its own TypeScript 5.9.3, which insulates it — but that's incidental rather than designed, and worth confirming before unpinning.

Not changing anything yet: the pin (#627) and the Dependabot ignore (#629) stay correct for now, and this deserves a proper PR rather than a spike. But "blocked until TS 7.1 lands around October" is not accurate, and shouldn't drive planning.

[lmorchard]

ts-json-schema-generator: not a TS7 blocker, but it does have a real parser-skew problem

Follow-up on blocker #2 in the table above. Two findings: it isn't a TS7 blocker at all, but the reason it's currently insulated is itself a latent hazard worth tracking separately.

The skew is real and measurable

generator:        ts-json-schema-generator 2.9.0
its typescript:   5.9.3      ← parses our source
repo typescript:  6.0.3      ← compiles our source

A full major version apart. typescript is a regular dependency of the generator, not a peerDependency, so pnpm gives it a private 5.9.3 no matter what the repo is on. That's the "incidental insulation" referred to earlier.

It matters more than it first appears because the generator runs against tsconfig.json and therefore parses all of packages/core/src/, not just events.ts. Any TypeScript 6-only syntax introduced anywhere in core would break schema generation. It works today only because we haven't used any yet.

An upgrade exists and is verified drop-in

Upstream merged "Upgrade to TypeScript 6, maintain TS5 compatibility" (PR #2509, Mar 2026). It has not been cut into a stable release:

Tag	Version	typescript dep	Published
latest	2.9.0	^5.9.3	2026-03-04
next	2.9.1-next.18	>=5.9 <7	2026-07-02

Tested locally by installing 2.9.1-next.18 and running the real generation:

generator:       2.9.1-next.18
its typescript:  6.0.3        ← shares the repo's copy; skew eliminated
check:schemas →  exit 0       ← byte-identical to the committed artifact

No schema regeneration needed, no diff, no other changes.

⚠️ Ignore 3.0.0-next.0 — despite the version number it was published in April 2024 and is a stale abandoned branch, not a future release.

Why this is not a TS7 blocker

Upstream explicitly capped the range at >=5.9 <7 rather than leaving it open, so they're aware of TS7 and excluded it deliberately. No stated TS7 plan found.

But the failure mode is benign. After upgrading, on TS6 the generator shares the repo's TypeScript. If the repo later moves to TS7, the <7 bound stops matching and pnpm simply installs a private TS 6.x for the generator again — it self-heals back to the insulated (skewed but working) arrangement rather than breaking the build.

So blocker #2 can be struck from the table. ts-json-schema-generator does not block a TS7 upgrade in either its current or upgraded form.

Alternatives considered, not recommended

events.ts is plain TypeScript types, not zod. So although zod 4.3.6 is already a dependency, moving to z.toJSONSchema() would mean rewriting the whole event type hierarchy as zod schemas — a large refactor for no current benefit. Every other TS-source-based generator (typescript-json-schema, ts-morph-based approaches) carries the same TypeScript-API dependency, and typescript-json-schema is effectively in maintenance mode.

Status: deliberately deferred

Holding off on the upgrade until a stable 2.9.1 is released. It's been on next since 2026-07-02 with no stable cut. The tradeoff:

• For upgrading now: closes a live one-major-version parser gap, verified zero-diff, and check:schemas is a CI gate so any regression surfaces immediately
• Against: it's a prerelease, and the hazard is latent rather than active — nothing is broken today

Waiting is reasonable. The thing to watch for is the trigger: if anyone hits a schema-generation failure after using newer TypeScript syntax in packages/core/src/, this is the cause and 2.9.1-next.18 is the fix.