Split TypeScript types up in codegen #16193
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors NodeJS/TypeScript code generation so that input, output and enumeration types are now generated in separate files near their resources. Previously, all inputs, outputs and enumerations would be grouped into a coarse-grained
types/*
module hierarchy, which hurts type checking performance in the case of large providers such as AWS (see #11558 and #10442, for instance). This commit changes code generation so that we now emitinput.ts
/output.ts
/enums.ts
files next to resources and functions as appropriate, rather than bundling them all into one large module. For backwards compatibility, the original module hierarchy has been preserved using re-exports until such a time as we decide to bump the major versions of our provider SDKs to remove it.I've tested this manually against the AWS Classic Provider, which as well as having many resources also has a series of overlays, and everything appears to build without any changes. Moreover, using the new fine-grained modules in the AWS case results in a sizeable reduction to the number of modules type checked (assuming some other changes to the aforementioned overlays are made), so I think if this works as expected it would pave the way to fix some of the linked performance issues. To give a taste of the difference:
Before
(all input types reside in this one module; importing
types
brings them all in, as does importing e.g.s3/bucket
, since that importstypes
)After
(types re-exported from fine-grained modules for backwards compatibility)
(fine-grained modules that if imported will only pull in minimal dependencies)
Obviously this could be a terrible way of going about it/a terrible idea in general. All feedback welcome 馃檹