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-strategyused by thetypescript-koatemplate to split the routes into separate files, based on either their firsttagor route segment.includes a lot of refactoring to support this:
ImportBuildernow supports relative paths in different directoriesTypeBuilder/SchemaBuildernow gets anImportBuilderscoped to the collection of routes being built for a given output fileJoiSchemaBuilderand fixed a few bugs in the processlint-stagedcommand foreslintthere'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->stringand 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
CompilationUnitintroduced in this change that can track interesting things and allow us to be smarter about how we organize the resulting files.