Generate a TypeScript API from our OpenAPI spec#457
Conversation
- return project name - ensure storage folder (and references.json) exists - always create directory for new projects - support return project files for desktop
- This will check check if the file exists in the project
- Remove dependency on tauri/fs APIs - Adopt HEAD in project filesystem to check if file exists - Add (initial) support to the SAMPLE project
- set project path for the sample project
|
@danvk everything looks nice to me. That TS code on |
|
@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 |
|
@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. |
|
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
left a comment
cguedes
left a comment
There was a problem hiding this comment.
This looks amazing 💪
Only added some notes to remove commented code.
|
Oh, also, test coverage goes up because:
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. |
3 participants
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:
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…api-paths.tsto use the types fromapi-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 patchapi-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
fetchfunction to it. Unfortunately, it's typed astypeof fetch, which means that we'd need to make a webfetch-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: