TypeScript OpenAPI Toolchain: One Week, Four Packages, Published to npm

The problem

I was starting a TypeScript migration at work. The library we depended on, openapi-typescript, did not support TypeScript 6 yet. I opened a pull request to add support.

The PR sat for six weeks. Someone offered $250 in sponsorship to get it merged. It stayed open.

That was enough. I opened a new session and started building a replacement.

The approach

The goal was clear: one OpenAPI spec file, one command, full-stack typed output. No runtime dependencies. No opaque abstractions. Generated code you can read, review, and commit.

I built four packages:

• @codewithagents/openapi-gen: TypeScript interfaces and a typed fetch client, one function per operation.
• @codewithagents/openapi-server: A generated server interface and Hono router. You implement the interface. TypeScript enforces it at compile time.
• @codewithagents/openapi-react-query: React Query v5 hooks, generated from the spec. Query key factories included. Test utilities generated alongside the hooks.
• @codewithagents/api-errors: RFC 9457 problem detail error mapping to form fields. React Hook Form adapter. Zero generated code.

The Zod integration is the design bet worth explaining. The generator bootstraps a schemas.ts from the spec on first run, then stops touching it. You own it. You add validation rules. On the next generate, the router is regenerated with your validation wired in. Client-side and server-side validation use identical rules from the same file. No sync required.

The full architecture is documented in the source blog post: The OpenAPI Toolchain I Built: One Spec, Zero Runtime, You Own the Output.

The compatibility matrix

The petstore demo proves the round-trip. It does not prove the generator handles production-scale APIs. So the repo ships a compatibility matrix: 128 real-world OpenAPI specs run in CI on every PR. They include Stripe, GitHub, OpenAI, Adyen, Spotify, Twilio, Resend, Twitter/X, and 120 more.

128/129 generate without errors. The one failure was a spec with a confirmed structural error upstream. On every PR, the matrix runs. A regression shows up as a diff, not a silent failure.

Building that suite was not just validation. The first batch found seven bugs in the generator, all fixed before the examples landed in main.

Beyond the matrix: a smoke suite generates clients against nine free public APIs and fires real HTTP requests. Proof the generated code does not just compile but actually talks to a live server. A full Playwright E2E runs on every PR, driving the browser-to-server round-trip. Three different ways to be wrong. Three different gates.

What the team said

I showed it at work. The answer was no, politely and completely reasonably:

"This new dependency is very fresh and only maintained by 1 person (you). It feels like adopting that dependency for our team, and this is definitely out of scope for us."

They were right. Single maintainer, days old, bus factor of one. I did not argue.

What I did instead: spent a few more evenings making it undeniable. Near-100% test coverage enforced in CI. Mutation testing with Stryker to verify the tests actually catch regressions. Static analysis on every PR via Fallow and CodeQL. The full story of the no and what came after it is its own post.

The outcome

Four stable packages on npm. A 128-spec compatibility matrix running in CI. Full-stack Playwright E2E. Near-100% coverage. Mutation score published publicly even when it is uncomfortable.

A proof-of-concept PR that wired the toolchain into the work codebase cut API-related code by about 50%. Half the hand-written client and test code, replaced by generated output you can read.

The toolchain is MIT licensed, public on GitHub at github.com/codewithagents/openapi-zod-ts. The PR that started it all is still open on the upstream repo. I stopped waiting.

What this means for your team

The question this case study answers is not "should you use this toolchain." The question is: what becomes possible when a single engineer with spare time and agentic workflows can produce a quality library that competes with established tools?

The compatibility matrix for 128 real-world specs took one session to design and a few hours to run. The mutation testing setup took less than a day. The full-stack E2E took an afternoon. Each of these would have taken a week at pre-agentic velocity.

That is the compound. Not "AI writes your code." The compound is that quality infrastructure, the thing most engineers skip because it takes too long, becomes fast enough to actually build.