Generate a TypeScript API from our OpenAPI spec

[danvk]

This PR sets up opeanapi-typescript to generate types from our OpenAPI spec. I also looked at openapi-typescript-codegen but it generates an enormous number of files and classes for each API, which isn't a good fit for how we work.

There are a few complications:

1. We actually have several APIs (settings, fs, projects, etc.). Having separate TS files for each of these would be a pain. To get a single TypeScript file, I had to merge all our OpenAPI specs.
2. The resulting API schema types are all defined in one big, nested interface. You can see what that looks like here. This isn't quite as nice as having all these types as distinct, top-level interfaces like we do now. I toyed with forwarding all the types, but this doesn't look as nice in your editor and you lose things like JSDoc. So I decided to keep our existing json2ts types (api-types.ts). Which leads us to…
3. I wanted to patch api-paths.ts to use the types from api-types.ts. I thought this would be find and replace, but they generate type names in ever so slightly different ways. So I wound up setting up a Python script to do some normalization and patch api-paths.ts.

So now we have types for requests / response and the various paths in our API available in TypeScript.

There's also openapi-fetch, which generates a runtime API for you with nice types. You can even pass your own fetch function to it. Unfortunately, it's typed as typeof fetch, which means that we'd need to make a web fetch-compatible version of Tauri's fetch. Yuck. I tried going down this path a bit but didn't like where I wound up.

Instead, I dropped openapi-fetch and decided to add types to the existing universalGet / universalPost / etc. APIs. This does mean some reinventing the wheel for what openapi-fetch does, but it's nice that we get to reuse the code that @cguedes already set up in #425.

There are still quite a few type assertions here because our API (in Python) is missing quite a few types.

In any event, you get nice types!

And autocomplete! (These are just the paths with POST endpoints.)

Still to do:

• Write some unit tests for Typed API
• Add the other HTTP methods (PUT, PATCH, DELETE)
• Update remaining API calls

[cguedes]

@danvk everything looks nice to me. That TS code on src/api/typed-api.ts is 🔥

[cguedes]

@danvk with the combined swagger spec we can now use this code to access the full api documentation via http://127.0.0.1:8000/docs.

api = FastAPI(swagger_ui_parameters={"url": "/combined.openapi.json"})


@api.get("/combined.openapi.json")
def read_openapi_json_file():
    return FileResponse("combined.openapi.json")

CC @gjreda

[gjreda]

@cguedes I don't think that will be necessary once I complete #415. See more here: https://fastapi.tiangolo.com/tutorial/bigger-applications/#check-the-automatic-api-docs

[cguedes]

@cguedes I don't think that will be necessary once I complete #415. See more here: https://fastapi.tiangolo.com/tutorial/bigger-applications/#check-the-automatic-api-docs

So I think @danvk won't need to merge the open API specs into a single file.

[danvk]

That does seem like a nicer way to get a combined OpenAPI but I think I'll leave that for another PR. We can remove my merging code once we do that.

[cguedes]

This looks amazing 💪
Only added some notes to remove commented code.

[danvk]

Oh, also, test coverage goes up because:

1. I'm excluding api-types.ts, which vitest previously counted as 285 uncovered lines.
2. typed-api.ts counts as 102 fully-covered lines.

Test coverage should probably ignore lines of code that only exist in type space (i.e. type declarations), but I'm not sure if vitest has a setting for that.