Large OpenAPI specs, generated SDK (Vue) typecheck cost, and the path to TypeScript 7.1

[j-westover]

Context

We are introducing @hey-api/openapi-ts codegen into the OpenBMC webui-vue project against the DMTF Redfish OpenAPI surface. The in-flight scaffold is on Gerrit:

Change 91407 — Add openapi-ts codegen tooling scaffold

That change adds openapi-ts.config.ts, Redfish spec patch helpers, fetch/generate scripts, and tooling wiring — without yet committing a generated src/client/ or changing runtime behavior. Follow-on changes in the same stack will populate scoped operations and wire the generated client into the app.

Redfish is a useful stress test for openapi-ts in the wild: the upstream YAML is enormous (thousands of schemas, deeply nested unions/intersections, heavy use of as const enum-style objects). Even when generation is scoped to a handful of BMC operations (~100 generated files, ~200 KB on disk), TypeScript still has a lot of work to do at typecheck time.

We have been benchmarking this pattern in a private Vue + TanStack Query reference app (same Redfish scope/split strategy). A public hey-api monorepo example is planned but not published yet; the numbers below come from that benchmark work and apply directly to webui-vue as scoped codegen lands.

This post summarizes what we measured, our interim CI workaround, and what we are waiting on upstream — especially TypeScript 7.1 — before we can collapse back to a single toolchain.

---

Where the time goes

For a Vue app consuming a scoped Redfish SDK, pnpm build is dominated by typechecking, not bundling:

Step	Typical time (macOS arm64)
vite build (no typecheck)	~9 s
vue-tsc --build --force (cold CI-style)	~4 min
vue-tsc --build (warm incremental)	~2 s

The cold cost comes from walking the entire generated SDK (src/client/**/*.gen.ts) plus Vue SFC consumers on every clean checkout / forced rebuild. Vite itself is fast; vue-tsc inherits TypeScript's single-threaded check loop.

Codegen against the full spec (local-only output for IDE/agent discovery) is a separate step. CI should build against a committed scoped SDK — no spec download, no codegen in the build path. The webui-vue Gerrit stack follows that model: scaffold first, scoped generation in a follow-on change.

---

What the hey-api workspace already does

Non-Vue packages in the openapi-ts monorepo typecheck with TypeScript Native Preview (tsgo) via tsgo --noEmit. That is already a large win for library packages.

TypeScript 7.0 RC (announcement) ships the Go-native compiler as tsc. On generated Redfish .ts files alone, tsc 7.0.1-rc finishes in ~0.2 s — but it cannot typecheck .vue SFCs, so it is not a drop-in replacement for a Vue app build like webui-vue.

---

Interim CI strategy (measured on our Redfish Vue benchmark)

Until Vue tooling can run on the native compiler, we split local vs CI scripts:

Script	Tool	When
typecheck / build	incremental vue-tsc	local dev (~2 s warm)
typecheck:ci / build:ci	golar	CI / clean checkout

Measured cold timings (June 2026, scoped SDK):

Approach	Cold typecheck	Cold full build (typecheck ∥ vite)
vue-tsc --build --force	~248 s	~248 s
golar typecheck	~73 s	~101 s

golar (~0.1.x) wraps @vue/language-core and parallelizes checks. It is good enough for CI cold builds today; it lacks incremental rebuild, so local warm runs are still slower than vue-tsc.

We plan to adopt the same split in webui-vue CI once scoped codegen is committed — golar for clean-checkout builds, incremental vue-tsc locally.

---

What we are waiting for (TypeScript 7.1)

The official path for Vue + native TypeScript is the TS 7.1 plugin API, tracked in microsoft/typescript-go#2824, with Vue-side coordination in vuejs/language-tools#5381.

Once vue-tsc (or equivalent) can host SFC checking on the native compiler — likely via that plugin API — we expect to:

1. Drop the CI-only golar workaround
2. Use a single tsc / vue-tsc --use-tsgo-style path for both local and CI
3. See cold typecheck times closer to what we already get on .ts-only slices (~seconds, not minutes)

We are not bumping generated-app projects to TS 7 RC wholesale yet: openapi-ts itself still uses the TypeScript 6 Compiler API at codegen time; programmatic API stability for tools is targeted for 7.1 per Microsoft's RC guidance.

---

Takeaways for other large-spec users

If you generate clients from massive OpenAPI documents (Redfish, cloud provider APIs, internal platform catalogs):

1. Scope what you commit — filter operations/schemas so CI typechecks a subset, not the entire spec surface.
2. Separate codegen from build — commit the scoped SDK; keep full generation local/optional.
3. Measure cold vs warm — incremental tsc/vue-tsc is often seconds locally; CI pays the cold bill.
4. Watch TS 7.1 + Vue tooling — that is the durable fix; interim tools like golar can bridge CI until then.

We are looking to publish a full hey-api monorepo example (config, benchmarks, repro scripts) once we get permission to release. In the meantime, the webui-vue Gerrit stack is the public place to follow OpenBMC + openapi-ts integration.

Happy to hear how others are handling typecheck time on large generated SDKs — especially Vue apps where native tsgo is not yet usable end-to-end.