feat: type definitions and documentation for separated type provider. #5427
Conversation
github-actions
bot
added
the
documentation
|
Will this be included in the new 5.0.0 release? I could start to create PRs for all the type-providers to support this change. |
|
cc @fastify/typescript what do you think? Should we do this? |
|
I encountered this same limitation recently while working with the Zod-type provider. I am +1 for this landing. Since I haven't worked recently on the type provider types, though, I am not sure how much breaking this PR is. |
|
@Bram-dc could you start preparing the matching PRs for our type providers? So we can land this for v5. |
|
@mcollina Could we have a npm publish to the "next" tag so that we can try this change in the plugins pipelines? |
|
This conflicts now, can you rebase? |
|
I think the conflict is resolved now, I did not completely understand the conflict. |
| @@ -1053,7 +1062,7 @@ expectAssignable(server.withTypeProvider<InlineHandlerProvider>().get( | |||
| // Handlers: Auxiliary | |||
| // ------------------------------------------------------------------- | |||
|
|
|||
| interface AuxiliaryHandlerProvider extends FastifyTypeProvider { output: this['input'] } | |||
There was a problem hiding this comment.
Why was this changed from { output: 'auxiliary' }
|
Could we have a "5.0.0-alpha.2" like 5.0.0-aplha.1 |
Fix for discussion: #5311
An update on a previous PR
This improved PR includes: