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.
introduces a new experimental option --grouping-strategy used by the typescript-koa
template to split the routes into separate files, based on either their first tag or route segment.
includes a lot of refactoring to support this:
ImportBuilder now supports relative paths in different directories
TypeBuilder / SchemaBuilder now gets an ImportBuilder scoped to the collection of routes being built for a given output file
Logic around generating the raw file content for output is now consolidated, and supports merging separate units together prior
Improved the unit tests for JoiSchemaBuilder and fixed a few bugs in the process
Fixed the lint-staged command for eslint
Replaced the jest reporter with one that's a bit quieter (still not perfect)
there's still quite a bit of impedance mismatch that makes outputting in different ways like this more
challenging than it would ideally be, mainly that we go straight from IRModel -> string and quickly
loose context of that string (eg: what imports it depends on, where it is used)
eventually we'll probably need to introduce some wrapping object, similar to the CompilationUnit
introduced in this change that can track interesting things and allow us to be smarter about how
we organize the resulting files.
introduces a new experimental option
--grouping-strategy
used by thetypescript-koa
template to split the routes into separate files, based on either their firsttag
or route segment.includes a lot of refactoring to support this:
ImportBuilder
now supports relative paths in different directoriesTypeBuilder
/SchemaBuilder
now gets anImportBuilder
scoped to the collection of routes being built for a given output fileJoiSchemaBuilder
and fixed a few bugs in the processlint-staged
command foreslint
there's still quite a bit of impedance mismatch that makes outputting in different ways like this more challenging than it would ideally be, mainly that we go straight from
IRModel
->string
and quickly loose context of that string (eg: what imports it depends on, where it is used)eventually we'll probably need to introduce some wrapping object, similar to the
CompilationUnit
introduced in this change that can track interesting things and allow us to be smarter about how we organize the resulting files.