openapi-typescript

Overly expressive type systems have way more potential for footguns than simple type systems. In fact, I would say that overly expressive type systems make it easy to create unmaintainable code (still waiting on this showstopping bug which nobody can debug because it uses overly expressive types in TS: https://github.com/openapi-ts/openapi-typescript/issues/1769)

I've seen some truly insane TS types. Ones that validate SQL queries and stuff. The problem with complex TS types is that there's no debug tooling. You can't set a breakpoint, you can't step through the type propagation. If there's an issue you have to just do trial and error, which can be very tedious. Here's a super complex type I ran into in the wild that has a bug that is extremely difficult to fix unless you burn hours on trial and error: https://github.com/openapi-ts/openapi-typescript/blob/main/p... (the bug in question, still unfixed): https://github.com/openapi-ts/openapi-typescript/issues/1769 It was so hard to fix this bug that I found it easier to just rewrite the entirety of the library but using code generation instead of ultra complex TS types to accomplish the same outcome.

Well it is. You won't discover how deep the rabbit hole goes with that type until you start trying to debug it. For example, try fixing this issue which is the result of a problem with that type: https://github.com/openapi-ts/openapi-typescript/issues/1769

> I must be a part of the problem because reading that type isn't too difficult. I also think types like this aren't innately problematic when they live in libraries. Despite the star count on the repo (which, if you aren't paying attention to the 0.X versioning, might lead you to believe it's a well tested "library" type), that particular type I linked to has a ton of bugs with it that are currently documented in at least half a dozen open issues, some of which are super esoteric to solve: https://github.com/openapi-ts/openapi-typescript/issues/1778... In this case ^ the problem was due to "behavioral differences based on the strictNullChecks ... compiler option. When that option is false (the default), undefined is considered to be a subtype of every other type except never" Maybe I'm old school, but as long as we are using metaprogramm

(tangential) In theory I like TS. But in practice, unless I'm the one writing it and can KISS, it can quickly turn into an unmaintainable nightmare that nobody understands. TS astronauts, left unchecked, can make extremely complex types using generics, conditionals, and all the esoteric features of TS, resulting in extremely obtuse code. For example, I doubt anyone could explain this "type" without studying it for several hours: https://github.com/openapi-ts/openapi-typescript/blob/main/p... In this case, the "type" is really an entire program.

Tbh, there is no benefit of using this package if the API you are working with has an openapi spec, as there are other great libraries to help you generate accurate types such as https://github.com/openapi-ts/openapi-typescript. But I made this package to use when working with external apis that don't have an available spec.

Maybe I just have bad luck, but most of the libraries I've tried that are "crazy to look at" seem good in theory but are janky in practice. For example, openapi-fetch (https://github.com/openapi-ts/openapi-typescript/tree/main/p...), on paper seems great, but has lots of jank in practice. And I would wager the bugs and jank are in no small part due to the extremely complex generics/constraints.

I'll preface all of this with a couple esoteric design goals that I had in mind: 1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc. 2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea. --- With that in mind, some specific packages that I highly recommend: 1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model 2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This mean

Another great library to generate TS types from OpenAPI is https://github.com/drwpow/openapi-typescript . It provides the types as single objects you access via indexing, which is pretty nice. There's a partner library to generate a typed fetch client.

I haven't done it yet. I've just set up a monorepo and prototyped sharing of types from backend to frontend. Googling it seemed like there were some decent options for type generation from swagger, i.e. https://github.com/drwpow/openapi-typescript