2026 Roadmap

[drwpow]

Hello from myself and the other maintainers of openapi-typescript! We’ve had a quieter 2025 than expected, so I wanted to share what we’ve been planning for 2026 which involve a few changes we wanted to broadcast:

TL;DR:

• ⬆️ openapi-typescript is still planning its 8.0 roadmap, and will keep getting better over time! Maintenance and updates will increase in 2026 as a result of focus.
• 🛑 openapi-fetch, openapi-react-query, and openapi-metadata will be put into maintenance mode and won’t get future updates, so we can put 100% of efforts back into openapi-typescript.
• ↪️ swr-openapi will be moving back to @htunnicliff’s ownership to continue maintenance & updates outside this project.

With the high points out of the way, we wanted to talk about the thinking and background that led to these decisions.

2025 was the year of npm vulnerabilities

We saw many npm vulnerabilities this year, notably different versions of Shal-Hulud supply chain attacks. openapi-typescript is almost at 2M downloads/week! Which means it’s a target for scammers.

Though security wasn’t originally a top priority for this project, the fact that openapi-typescript still has its original creator as one of the maintainers (me), and is very light on dependencies (for many versions, zero), has contributed to this project having a clean security record (the only known vulns in the project have been in devDeps, such as the documentation website, etc.—nothing consumers would ever install). But in response to all that’s happened, security now is a priority, and we want to continue this project’s clean track record by minimizing surface area, continuing to be hyper-selective on dependency addition, and reducing maintainer strain. We want to do this by focusing on the core: static OpenAPI <> TS integration of openapi-typescript. And improving security by reducing runtime impact.

For a safer, better future of OpenAPI + TypeScript, these all suggest on focusing on openapi-typescript—and only openapi-typescript—for 2026.

2025 was our first full year of growing maintainers

Though we had our first non-Drew maintainer join in 2024, and folks join through the end of 2024, this was the first full calendar year we had 4-5 folks all sharing ownership of the project. We know this hasn’t magically resulted in 5x faster response times, 5x the versions, etc. etc. In complete transparency there were some growing pains! There was some bystander effect. All the maintainers joined are incredible engineers, and it was no fault of their own, rather me (Drew) doing a poor job at organizing and leading maintainers to the correct action and priorities.

As of now, @kerwanp has decided to step down in 2026 as maintainer due to life changes, and the remaining 4—myself, @htunnicliff, @gr2m, and @duncanbeevers, will kick off maintainer (re)commitments in 2026 and work to improve the current process.

So all that said, a huge “thank you” to contributors and participants in issues and PRs for being patient with some new processes, and the parts of project management that didn’t go as well as it could have 💙.

Halting maintenance on the fetch clients (openapi-fetch and friends)

Moving openapi-fetch into maintenance mode (and the other projects built on it) isn’t a decision we take lightly, especially since these projects have been well-received, and also receive a lot of downloads (openapi-fetch is also almost as downloaded as openapi-typescript)! We also don’t want to simply hand them off to an unknown, outside party for the security concerns just mentioned, and break the trust we’ve built over the years. By moving them into maintenance mode, everything will continue to “Just Work” without any risk to consumers, and will give folks time to migrate.

Background & motivation

In addition to the security concerns, there are several related realizations we’ve had over the course of the openapi-fetch project that all point to this being beyond our current ability to maintain:

1. Fetch clients should be a little more runtime-aware.

   openapi-fetch promised to be a “zero-build, zero-runtime” library where plugging it up to OpenAPI TS definitions Just Works™. But we have had myriad issues around folks being confused why default params have to be retyped, why information has to be duplicated over-and-over again, etc., and it really boils down to a consumer misunderstanding around what “zero-runtime” really means. Further, in some instances it increased overall client weight through duplicated information! I (Drew) as an OSS developer, am strongly against the “you’re just holding it wrong” philosophy, recognizing that at a certain point, having many smart software developers being confused about something, means the design should be revisited and improved.

   Anecdotally, most consumers if given the choice would take on a build step, and a few more kB over-the-wire if they didn’t have to duplicate information over and over again between their endpoints or maintain annoying openapi-fetch wrappers to house this information.

   The takeaway is we believe “zero-build, zero-runtime” in the absolute sense to be a bit of a dead end. However, having a lightweight, performant API SDK is desirable. That is a different project from openapi-fetch (there are dozens of existing solutions today), and this new project is beyond the ability for us to take on at this time.

2. The ideal stack usecase of openapi-fetch is too disparate.

   Let’s take a step back at the global developer communities around APIs. For folks running a TS frontend + TS backend, tRPC is a good choice. Many folks reaching for openapi-fetch, then, often are searching for solutions for TS frontend + non-TS backend (usually). This is such a wide, disjointed cluster of disparate developer communities that spans Go, Ruby on Rails, Python, Elixir/Phoenix, and more. Each individual community has its own rich ecosystem of SDK generation, that openapi-fetch may be barring folks from tapping into. We believe folks can get more benefit out of leaning deeper into their individual communities, than having one-size-fits-all here.

3. The future of TypeScript may look different.

   TypeScript support has an exciting future ahead, between a proposal for ESM to support types and Node.js now running types natively. The exciting thing about software development is that things get easier over time.

   In a world where TypeScript execution is now first class, we’d revisit how openapi-fetch works, to the point it would be a different end-project to what it looks like today. But because we don’t have the maintainer resources to focus on runtime, we’ll save that future exploration for tomorrow, and for today, simply declare “openapi-fetch, on its own, is not a complete solution for many folks” and lets the millions of other smart developers solving this problem to help carve the path forward.

Sure, all these points don’t form a complete, clear solution for everyone. They lead to more questions than answers. But we think they all point away from openapi-fetch for the moment, and that’s the realization here.

Migration guides

With all that said, here’s what it practically means for folks:

From openapi-fetch

Though a migration guide is future/TBD, expect to see upcoming guides that explain how to building and maintaining your own local openapi-fetch in your project, which will allow you to customize and maintain it (similar to shadcn, which is a popular UI kit library that is geared around local customization rather than a traditional npm dependency chain). Because openapi-fetch at the end of the day was only a few kB, most folks will have a better experience managing it themselves locally.

From openapi-react-query

This will, unfortunately, be more painful for most folks. But with TanStack Query developing at a rapid pace (and even getting deeper integration into new projects like TanStack Start), we think this will be a better long-term experience for most folks not being the bottleneck to the TanStack ecosystem, with new features often being gated behind our inability to keep pace with those projects.

From swr-openapi

For users of swr-openapi, no migration needed! 🎉 This project will continue to be maintained under @htunnicliff’s stewardship (the original owner/creator—no hands are being changed here, either). Hunter will continue to be a maintainer of openapi-typescript as well, but will take on sole ownership of swr-openapi again. The package name won’t change and versioning will continue, and over the next few months we’ll move the source code back to the the original repo.

opeanpi-typescript 8.0

With the bad news out of the way, we’ll end on good news! Though the roadmap is still TBD as of the time of this post, here are some of the things we’ve talked about, which may or many not make it into the final version (many courtesy of @duncanbeevers who has been leading this effort):

• Composability: the most-requested addition of openapi-typescript has been the ability for folks to more easily slice-and-dice parts of their schema, and reference deeply-nested structures without having to chain["everything"]["in"]["a"]["really"]["annoying"]["way"]. This is essentially taking the --root-types flag, making it first-class, and providing even more utility around this. In fact, in a certain manner of speaking, openapi-fetch’s success may have been due in part to openapi-typescript’s lack of generation options—in a world where more can be generated, users may be able to build bigger and better things than openapi-fetch!
• Server-side validation: Runtime-validating projects like Zod have been around for a while, and continue to get wider adoption and have more breakthroughs. openapi-typescript historically has been a “zero-runtime” project, however, we’re more open to finding backwards-compatible ways to play nicer with tools like Zod since most consumers end up having to manage both.
• Better JSON Schema support: Even though OpenAPI 3.0 is a superset of JSON Schema, actual support for JSON Schema features hasn’t always been a first-level concern for openapi-typescript. For example, it’s never been possible to, say, specify your OpenAPI schema uses Draft 2020-12 rather than Draft-07. We think, even with stellar projects like ajv existing, there’s still a lot of missing gaps when it comes to broader JSON Schema <> TypeScript interop.
• OpenAPI 3.2: (Not requiring 8.0 specifically) With OpenAPI 3.2 released in Sep 2025, there are now OpenAPI features not fully supported in openapi-typescript. Our top priority is to always have 100% support of OpenAPI features, and we’re currently behind where we want to be with that.
• OpenAPI 4: OpenAPI 4.0 seems a little further away in Dec 2025 than it did at the start of the year. While 8.0 won’t be delayed by OpenAPI 4.0 release, we’d love instead to start shipping experimental flags that make it easier for consumers and spec authors to kick the tires on future ideas. Even if they never reach stable status.

There are more ideas, of course, but this is just a small sampler of what could be. Especially as we start 2026 with renewed interest and support for the project.

Thank you!

And of course, a big “thank you” to all contributors, folks that opened or commented on issues, and downloaded and used the project over 2025 (and previous years). Thank you for your patience in some instances where we, the maintainers, haven’t always responded in a quick manner, or unblocked bugfixes and features from shipping. Even for the issues and PRs today we haven’t replied to, just know we hear and see you and are eternally grateful for all the work you continue to put into this project. And we’re writing this post, and focusing efforts, so that ultimately we can be more responsive, and ship versions faster in 2026.

Here’s to a new 2026 of even better tooling for OpenAPI + TypeScript! 💙

[johnnyreilly]

Thanks for sharing this! I'll confess to be quite gutted to here openapi-fetch is being deprecated. I'm still fairly new to it and I haven't had the issues you reported. Perhaps I'm just lucky.

I had some questions if I may.

For folks running a TS frontend + TS backend, tRPC is a good choice. Many folks reaching for openapi-fetch, then, often are searching for solutions for TS frontend + non-TS backend (usually).

Yup. This is me exactly.

This is such a wide, disjointed cluster of disparate developer communities that spans Go, Ruby on Rails, Python, Elixir/Phoenix, and more. Each individual community has its own rich ecosystem of SDK generation, that openapi-fetch may be barring folks from tapping into.

I can't comment for the examples you reference, but the C# ecosystem does have something in the form of NSwag but it's probably less well maintained than openapi-fetch I'd say. One of my motivations for using openapi-fetch with openapi-ts was because there isn't much in terms of SDK generation that I'm aware of that seems superior.

I've written about NSwag usage here for reference: https://johnnyreilly.com/generate-typescript-and-csharp-clients-with-nswag

expect to see upcoming guides that explain how to building and maintaining your own local openapi-fetch in your project, which will allow you to customize and maintain it

Would you be able to say a little more about this when you get a moment please? I'm curious as to what this might look like. I think I'm also curious as to why this wouldn't fit in openapi-fetch as is? Obviously you're under no obligation to build / maintain openapi-fetch but I'm wondering why everyone building their own would be preferable. I realise I'm writing from ignorance here - no doubt the reasons are excellent! It'd be awesome to understand them better.

This is essentially taking the --root-types flag, making it first-class, and providing even more utility around this.

This is brilliant news!

[drwpow]

I'll confess to be quite gutted to here openapi-fetch is being deprecated.

expect to see upcoming guides that explain how to building and maintaining your own local openapi-fetch in your project, which will allow you to customize and maintain it

Would you be able to say a little more about this when you get a moment please?

Yeah! Thanks for taking the time to reply. I really do think you’re representing (accurately) one of the main users of openapi-fetch, and highlight some of the problems of the ecosystem today.

The original project started because of the myriad papercuts I had using the official swagger codegen (OpenAPI 2.0), and how bad/slow it was at adopting TypeScript. The core of this project comes directly from the frustration of how bad SDK generators can be, and trying to find lower-level, more generic solutions.

But the problem with trying to generalize all backends into one solution means we trivialize them. OpenAPI has support for WebSockets, for instance, but openapi-fetch can’t utilize those. openapi-fetch doesn’t really support security/auth well. The middleware it does support isn’t always what folks need. So in practice, we were finding 2 major groups of devs that used openapi-fetch:

1. Trivial setups: a very simple REST API, where openapi-fetch is only doing some basic fetching. There is some type safety to reduce developer accidents, but openapi-fetch being zero-runtime depends on absolute trust of the backend.
2. Complex setups (WebSockets, etc.): openapi-fetch doesn’t know about more advanced layers of the server, so folks build complex wrappers around openapi-fetch which leads to it being critical infrastructure.

While we admit we were trying to make openapi-fetch fit both usecases originally, we now feel like the following approaches may benefit most folks better:

1. Managing your own wrapper for trivial setups: If only basic operations are needed anyway, openapi-fetch could be recreated following a docs guide. It’s a lot less code than people realize. Plus, if we do decide to improve openapi-typescript generation to, say, support Zod or other libraries in 8.0, then it opens up the possibilities for what folks can do, without restrictions.

2. Reaching for an SDK for complex setups: This may be where you find yourself groaning, because the SDK generators for your backend may be lacking or terrible (like NSwag, though I haven’t tried that one myself). But whether folks choose to reach for an open source, commercial, or homegrown solution here, we feel that just removing openapi-fetch from the equation will lead to better long-term decisions.

   As someone that’s contributed to a large number of open source projects, and even worked in multiple DevTools/DX for-profit startups, the hard lesson I’ve had to learn over and over again is one-size-fits-all solutions are often a lie. The tradeoffs made in decisions for backend—language, instance, scaling—do actually affect the shape of the API, and ultimately affect the client. It affects how the client needs to navigate and optimize this structure in a way that works best for the user—e.g. whether or not APIs must be serialized and/or parallelized, and when.

   All that to say, trying to trivialize a complex setup that arose from a complicated, layered history of needs, usually doesn’t work well long-term. The scary part is when you don’t realize what’s not working well until 1+ year in. And the truth is, the openapi-typescript project just doesn’t have the resources to support all these really unique, complex setups. And we’ve gotten more issues opened on opeanpi-fetch than openapi-typescript because of all the gaps in openapi-fetch’s runtime.

Sure, it’s not fun to take what feels like a solution away from folks. The contract of openapi-fetch will continue to be “if it works, it works; continue to use it as long as you need.” But we’re just realizing that as folks have now started to use it beyond the one-year mark, we just can’t grow and evolve the openapi-fetch project in the way that consumers have verbalized they need us to.

[drwpow]

And the truth is, the openapi-typescript project just doesn’t have the resources to support all these really unique, complex setups. And we’ve gotten more issues opened on opeanpi-fetch than openapi-typescript because of all the gaps in openapi-fetch’s runtime.

Sorry—to clarify, I’m trying to suggest that improvements to openapi-typescript may be able to fill more gaps than openapi-fetch did. Not that the projects will be combined, rather, when us maintainers talk about all we’ve learned over the past couple years, and all the ways folks needed openapi-fetch to work but it didn’t, we’re realizing that there are probably just more things openapi-typescript could generate, that lead to better outcomes for a more diverse set of problems. Which is why we want to focus on openapi-typescript. Since, again, openapi-fetch really only used openapi-typescript generated types in a clever way 🙂.

[johnnyreilly]

That's really helpful - thank you.

In my case I suspect I'm in the trivial setup camp. I tend to have an ASP.NET web app running in a docker container with a SPA front end built with Vite bundled as static assets in the container.

As such, there's no Auth to worry about and we've a build validation that ensures client and server are aligned:

https://johnnyreilly.com/keeping-front-end-and-back-end-in-sync-with-nswag-generated-clients

I look forward to seeing what happens and thank you for your work!

[mrlubos]

Incredibly well written and thoughtful post. I was wondering myself why the activity slowed down, but assumed life got busy between the new (fancy, may I add) job and family. Happy New Year!

[JeanRemiDelteil]

Thank you for taking the time and energy to communicate on this.

As for us, we started by using openapi-fetch to bootstrap our use of openapi-typescript, but we were quickly forced to switch to building our own fetch implementation for more flexibility in the fetch API.
For example we wanted to have automatic actions derived from links sent by API ressources.

Another point is that we always want to validate the content sent by the server, as it should not be trusted by default, or some value should be deserialized in some particular way (DateOnly, etc...).
That led to having to redeclare things in the front (not nice, but they were statically compared with the back at least).

[thomasboyt]

I am very curious how people are building their own fetch implementations against openapi-typescript schemas while keeping type safety. Because, on this note:

Managing your own wrapper for trivial setups: If only basic operations are needed anyway, openapi-fetch could be recreated following a docs guide. It’s a lot less code than people realize. Plus, if we do decide to improve openapi-typescript generation to, say, support Zod or other libraries in 8.0, then it opens up the possibilities for what folks can do, without restrictions.

I spent the last couple hours digging into openapi-fetch's type definitions and I can't say I have a good grip on how I would apply any of this to my own code. There are a lot of helpers and things that I cannot get to type check quite right when trying to reimplement a simplified version of openapi-fetch ("simplified" being no middleware, assume always json, etc.).

I do imagine maybe some off-the-shelf helpers with documentation and guidance could help here, but it really would need to walk users through some advanced TypeScript features to get things typed correctly.

[panwauu]

I just read this and am concerned about the future of openapi-fetch. Honestly for me it was working very well and served exactly the purpose it was supposed to. To ensure type-safety between a python backend and a vue frontend.
If they are now in maintenance mode then it should be noted in the documentation such that new users do consider the missing updates/bugfixes in the future when making a choice.

Thanks for the work you did for the community!

[emanuelen5]

Same use case here with Python backend (but React frontend), and it has worked beautifully for me. I agree - thanks for all the work!