A code generation tool for openapi 3 / 3.1 specifications written in typescript, primarily aimed at generating typescript clients and server stubs. Other target languages may be added in future.
Generates routes following the app router "Route handlers", with a mirrored directory structure of companion files under ./src/generated containing the types and validation boilerplate
Approach
Due to the NextJS file based routing paradigm I couldn't see anyway to avoid manipulating files that will contain manually written code.
This is a major shift compared to the other templates which treat all emitted files as disposable.
To achieve this we employ ts-morph to (hopefully) safely modify the app router files without destroying the manually written implementations.
Currently there is a lot of duplicated code between this and the typescript-koa template which needs rationalizing, as well as it depending on the typescript-koa-runtime package. Part of the motivation behind this is to have more than one server template to allow it to become more generic like the client templates.
Because of the typescript-koa-runtime hack, to actually use this in a NextJS application you need to add the following to your next.config.mjs:
I also don't love the explosion of files this creates when running the standard set of integration suites, and might limit the scope down to one spec to reduce the noise. Ideally I'd like to separate the integration tests to their own repo and also start testing more permutations of options (eg: joi, extract-inline-schemas).
Additionally to make multiple suites play nicely I've had to fudge the output paths in the tests, technically producing incorrect routes.
Performance
I've been told that ts-morph can be relatively slow, so it's probably useful to check the performance between this and typescript-koa
Overall it looks similar, aside from calculation of the dependency graph. I'm not sure if this is the bug in the timing code, or if the larger number of compilation units is somehow causing this. Warrants some investigation in case we're calculating it repeatedly or something.
Creates a new
typescript-nextjs
template./src/generated
containing the types and validation boilerplateApproach
Due to the NextJS file based routing paradigm I couldn't see anyway to avoid manipulating files that will contain manually written code.
Pending Refactoring
Currently there is a lot of duplicated code between this and the
typescript-koa
template which needs rationalizing, as well as it depending on thetypescript-koa-runtime
package. Part of the motivation behind this is to have more than one server template to allow it to become more generic like the client templates.Because of the
typescript-koa-runtime
hack, to actually use this in a NextJS application you need to add the following to yournext.config.mjs
:I also don't love the explosion of files this creates when running the standard set of integration suites, and might limit the scope down to one spec to reduce the noise. Ideally I'd like to separate the integration tests to their own repo and also start testing more permutations of options (eg:
joi
,extract-inline-schemas
).Additionally to make multiple suites play nicely I've had to fudge the output paths in the tests, technically producing incorrect routes.
Performance
I've been told that
ts-morph
can be relatively slow, so it's probably useful to check the performance between this andtypescript-koa
Overall it looks similar, aside from calculation of the dependency graph. I'm not sure if this is the bug in the timing code, or if the larger number of compilation units is somehow causing this. Warrants some investigation in case we're calculating it repeatedly or something.
typescript-nextjs - api.github.com.yaml
typescript-koa - api.github.com.yaml