Skip to content

Latest commit

 

History

History
65 lines (49 loc) · 2.57 KB

TODO.md

File metadata and controls

65 lines (49 loc) · 2.57 KB

TODOs

There are a lot of smaller TODOs throughout the codebase. Here's a brief list of larger considerations that, due to a lack of need, haven't yet been handled. Feel free to jump in.

Integration with Fastify v4 Type Providers

Expected difficulty: moderate

Fastify v4 is on the way and includes type providers that make it easier to, in a generic fashion, specify validators for request bodies, responses, etc. that also act as inferrable generics. I have not yet looked at v4, but we do internally use @sinclair/typebox for everything and so I don't foresee this being a huge lift--just somewhat tedious to get right.

Top-Level Servers Block

Expected difficulty: low

Right now, if you generate an OAS client from a spec generated from this client, you need to pass the base URL. Which is silly. However, there's some weird interplay between the prefix assigned to this plugin, the routes declared in the same scope, and the base URL of the server. Just needs somebody to think about it.

Links Objects

Expected difficulty: low

I don't use link objects. If you do, I'm definitely interested in discussing both how we can implement it and how we can make writing them pleasant.

Example Objects

Expected difficulty: moderate

Some example objects are free with the way that schemas work, but responses, etc. need some thought.

Header Response Schema

Expected difficulty: development low, design moderate/hard

Right now, @eropple/fastify-openapi3 is unaware of headers in responses because I haven't needed them (and also they don't really plug into the way Fastify does things too well). Suggestions welcome!

Alternate Content Types

Expected difficulty: moderate

@eropple/fastify-openapi3 expects that every request body and every response is application/json. There are two bits to this:

  • Some APIs, for good reasons, use vnd extensions to media types to indicate API versions.
  • Some folks want to send things that are not JSON.

The former is just changing the schema alias in the plugin (it's a constant, so it's not a snap-your-fingers fix) but the latter requires additional thinking. And OpenAPI isn't great at that anyway. So some insight from an invested party would be awesome.

In the interim, you can bail out by using oas.custom and do whatever you want to do, but that's a little awkward.

Things We Won't Support

  • server blocks at path/operation level
  • using $id for schema identification
  • any particular ergonomics for folks not using TypeScript. Use TypeScript.