We Upgraded to TypeScript 7.0, and It Was Almost Boring - Elyra v0.9.13

Here's a release note that sounds like nothing and means a lot: Elyra now builds on TypeScript 7.0. No new commands, no new models, no user-facing anything. Just the compiler underneath everything got replaced — and the story of how uneventful that was is actually the interesting part.

Why TypeScript 7.0 matters

For over a decade, TypeScript's compiler (tsc) was itself written in TypeScript, running on Node. It was correct and beloved, but on large codebases it got slow — type-checking a big monorepo could take minutes, and the editor could lag behind your keystrokes.

TypeScript 7.0 is a native port of the compiler, rewritten in Go. Same language, same type system, same behavior — but native code speed and real multithreading. Microsoft's numbers on real projects:

Codebase TS 6 TS 7 Speedup vscode 125.7s 10.6s ~12x sentry 139.8s 15.7s ~9x playwright 12.8s 1.47s ~9x

And it's not just full builds — the editor experience (find-references, autocomplete, red squiggles) drops from seconds to fractions of a second. For a project like Elyra with many packages, that's the difference between "type-check runs in CI while I get coffee" and "type-check finished before I looked up."

That's the why: faster feedback loops, everywhere, for free.

How the upgrade actually went

Here's the part I want to be honest about, because it's the most useful lesson: the upgrade was nearly a no-op, and that's not luck — it's the payoff of prior groundwork.

We were already halfway there

Elyra had been using the native compiler in preview form (tsgo, via @typescript/native-preview) for the root type-check and all package builds. So the "scary" part — does our code even pass the native checker? — had effectively been answered for months. TypeScript 7.0 stable is just that compiler, finished.

The migration, in one line

The entire code change was bumping one dependency across the workspace:

-  "typescript": "^6.0.3"
+  "typescript": "^7.0.2"

That's it. Five package.json files, one version string each. No source changes. No tsconfig changes.

Why nothing broke: the config was already clean

TypeScript 7.0 turns a bunch of old, deprecated settings into hard errors — baseUrl, moduleResolution: node/classic, target: es5, module: amd/umd, and so on. This is where many projects stumble. Ours didn't, because tsconfig.base.json was already modern:

{
  "compilerOptions": {
    "target": "ES2024",
    "module": "Node16",
    "moduleResolution": "Node16",   // not the removed "node"/"classic"
    "strict": true,
    "esModuleInterop": true,        // 7.0 requires this stays true
    "types": ["node"]               // 7.0 defaults to [] — we were explicit
    // no baseUrl, no es5, no amd/umd
  }
}

Every one of 7.0's new hard errors is something we'd already avoided. The upgrade found nothing to complain about.

The one snag (and why I'm telling you about it)

The upgrade itself was clean, but the release hit a small bump that's worth sharing, because it's a great illustration of a coverage gap rather than a TypeScript problem.

Our npm run check type-checks the core and the UI packages — but not the SDK examples. One example still referenced a model that had been removed from the registry in an earlier data refresh:

// examples/sdk/12-full-control.ts
const model = getModel("anthropic", "claude-sonnet-4-20250514"); // ← gone

Because getModel's second argument is strictly typed to real model IDs, this is a compile error — but only the publish build compiles the examples, so it sailed past check and surfaced at release time. The fix was a one-liner:

const model = getModel("anthropic", "claude-sonnet-5"); // current default

The lesson isn't "TypeScript 7 is risky." It's the opposite: a strict type system caught a stale reference that a looser setup would have let ship as a runtime crash. The real bug was our check not covering examples — now on our list to fix so it's caught before publish, not during.

What you get

If you use Elyra, you don't need to do anything — this is entirely under the hood. If you develop on Elyra or build extensions against its packages, your type-checks and editor now run on the native compiler, and you're on the same stable toolchain as everyone else. No version skew, no nightly-preview surprises.

npm install -g @elyracode/coding-agent@0.9.13

The takeaway

The best infrastructure upgrades are the ones you barely feel. TypeScript 7.0 gave us an order-of-magnitude faster compiler, and because we'd kept our config clean and had been dogfooding the native preview, adopting the stable release cost us a single version bump. The only excitement was a stale model ID in an example — caught, fittingly, by the very type system we were upgrading.

Sometimes "almost boring" is exactly what a release should be.