openapi-typesafe — type-safe OpenAPI clients, ready for TypeScript 7
A maintained, drop-in successor to openapi-typescript and openapi-fetch, whose author stopped maintaining them in September 2026. It generates TypeScript types from an OpenAPI 3.0, 3.1 or 3.2 schema and gives you a fully typed fetch client. The generator no longer uses the TypeScript compiler API, so it works on TypeScript 5, 6 and 7. Every release is checked against 1,820 real-world schemas: 50,960 cases, 0 unexpected differences.
- Role
- Maintainer — fork, generator rewrite, compatibility testing, release pipeline
- Stack
- TypeScript · Node.js · OpenAPI 3.x · Vitest · GitHub Actions · npm provenance · VitePress
- Period
- Nov 2026 — present
Generate the types, then call your API with a typed client:
npx openapi-typesafe ./openapi.yaml -o ./src/api/schema.d.tsWhy it exists
openapi-typescript and openapi-fetch are
how a lot of TypeScript teams talk to their APIs: you point them at an OpenAPI schema and get types
for every path, parameter and response. In September 2026 their author
stopped maintaining them.
At the same time TypeScript 7 arrived. It is the native port of the compiler, and its typescript
package has no JavaScript API: no ts.factory, no printer. openapi-typescript builds every type
with ts.factory, so in a project on TypeScript 7 it either refuses to install or crashes the
moment it loads.
So thousands of projects had a dependency that was both unmaintained and about to break.
What I did
I forked it with the full upstream history and set one rule: migrating must be a package rename, nothing more. The same CLI flags, the same Node API, the same generated output, the same client.
- A generator without the compiler API. Types are built as a small tree of our own and printed
by our own printer. It needs no
typescriptpackage at all, so it runs next to TypeScript 5, 6 or 7. - OpenAPI 3.2 support, which the original rejects.
- A migration tool (
openapi-typesafe-migrate) that moves a project over: imports, scripts and package settings. - TanStack Query bindings and shared type helpers, as drop-in replacements too.
How I know it's compatible
"Drop-in" is a promise, so it has to be measured, not claimed. A public compatibility report compares our output with openapi-typescript 7.13 on 1,820 real OpenAPI documents: the whole APIs.guru directory plus the big ones like GitHub, Stripe, OpenAI, Cloudflare and Kubernetes. Each schema runs with 28 option sets, so 50,960 cases.
Every case is checked in three steps: same bytes, then the same types (a strict identity check), then whether it compiles. The last run: 99.87% byte-for-byte identical, 100% identical types, 0 unexpected differences. CI runs the full corpus every night, and every release links its report.
Secure releases
A code generator runs on your machine and writes code into your project, so its supply chain matters:
- minimal dependencies;
- npm provenance and no long-lived publish tokens;
- a threat model, a security policy with response times, and private vulnerability reporting;
- OpenSSF Scorecard and OpenSSF Best Practices badges.
Built for coding agents
The repo ships an agent skill that teaches Claude Code (or any agent that reads skills) how to
set up the client, make typed calls, handle errors, and migrate from openapi-typescript. A separate
eval suite measures that skill on 34 coding tasks. The docs site serves llms.txt,
llms-full.txt and a Markdown copy of every page.
I built it with agentic engineering: coding agents write the code, and I own the design, the compatibility rule and the proof that it holds.
Status
Release candidate: 1.0.0-rc.4 on npm. Names and output may still change before 1.0.0, then it
follows semantic versioning. MIT license.