feat: response body validation and types#29
Conversation
needs very refinement / cleaning up, but adds preliminary response body validation to typescript-koa template
There was a problem hiding this comment.
There's a pretty significant performance drop in terms of running typescript on the output of this branch, though I'm not sure there's much to be done about it - there's ~100k additional lines of code generated.
Before:
time yarn workspace typescript-koa validate
yarn workspace typescript-koa validate 8.84s user 0.28s system 206% cpu 4.425 total
After:
time yarn workspace typescript-koa validate
yarn workspace typescript-koa validate 29.11s user 1.01s system 147% cpu 20.470 total
The github API spec can probably be considered unusually large/complex so perhaps it won't matter in practice.
There was a problem hiding this comment.
Moving named schemas to their own file / duplication reduced timings to ~15s. Had a play with replacing the numerical literal types with template literal ones like 2${number}${number} but saw minimal difference - pretty confident the slow down is purely the number of (complex) values to type check
reduces duplication and speeds validation of integration tests up by approximately 25%
| return {} | ||
| } | ||
|
|
||
| export function ifElseIfBuilder(parts: ({ condition?: string, body: string } | undefined)[]) { |
There was a problem hiding this comment.
Unused from a previous iteration of this branch
There was a problem hiding this comment.
Keeping as something potentially useful, might get culled later
| throw new Error(`unexpected status string '${status}'`) | ||
| } | ||
|
|
||
| const responseSchemas = Object.entries(operation.responses ?? {}).reduce((acc, [status, response]) => { |
There was a problem hiding this comment.
This feels like it should be extracted into it's own thing, but I think this will happen as part of supporting multiple response content types
1 participant
closes #11