-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use DirectedCodegen #548
Use DirectedCodegen #548
Conversation
9b76732
to
de838cc
Compare
0c166f5
to
69280b6
Compare
smithy-typescript-ssdk-libs/server-common/src/validation/validators.ts
Outdated
Show resolved
Hide resolved
...c/main/java/software/amazon/smithy/typescript/codegen/integration/TypeScriptIntegration.java
Outdated
Show resolved
Hide resolved
Looking good! |
5ec7130
to
21cd6f7
Compare
// Write each custom file. | ||
for (TypeScriptIntegration integration : directive.context().integrations()) { | ||
LOGGER.finer(() -> "Calling writeAdditionalFiles on " + integration.getClass().getCanonicalName()); | ||
integration.writeAdditionalFiles( | ||
directive.settings(), | ||
directive.model(), | ||
directive.symbolProvider(), | ||
directive.context().writerDelegator()::useFileWriter); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this loop here can be removed by moving integration.writeAdditionalFiles
to integration.customize
which CodegenDirector will call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be awesome if we can do it in the same customization loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this can be done as a refactoring later.
shape.accept(this); | ||
} | ||
} | ||
for (Shape shape : TopologicalIndex.of(model).getRecursiveShapes()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the generated shapes are not topo sorted. It causes a lot of import statements in the models_0.ts
from models_1.ts
and vise versa. It will cause the TS compliler consumes more memory than it needs. Can you add the toposort to the new directed codegen visitor? We want models_N.ts
file only has import statement to its previous files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will also make the generated diff a lot cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want models_N.ts file only has import statement to its previous files.
Hmm, I didn't understand this mattered.
Shape generation already does do topo sort.
This reordering is because CodegenDirector does generation for Service before visiting shapes. I thought this rearrangement was not a big deal other than 1 time diff. But now I'm going to evaluate to confirm if it is good to switch the order of those steps in CodegenDirector for all generators - seems reasonable to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the order in Smithy - smithy-lang/smithy#1289. Will regenerate SDKs once approved to confirm diffs are gone.
// TODO: do all of these parts below are before/after? | ||
SymbolVisitor.writeModelIndex(directive.connectedShapes().values(), directive.symbolProvider(), | ||
directive.fileManifest()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a new customization interface to modify the model or settings? If so we need to run it before generation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is not a new customization. This is just what CodegenVisitor did at here to write the models/index.ts
. So this seems in the correct place. I meant to remove that TODO but forget. Removing now.
// Write each custom file. | ||
for (TypeScriptIntegration integration : directive.context().integrations()) { | ||
LOGGER.finer(() -> "Calling writeAdditionalFiles on " + integration.getClass().getCanonicalName()); | ||
integration.writeAdditionalFiles( | ||
directive.settings(), | ||
directive.model(), | ||
directive.symbolProvider(), | ||
directive.context().writerDelegator()::useFileWriter); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be awesome if we can do it in the same customization loop.
Doesn't generate everything though, but compiles and can run the generator
Generates static files, index.ts, etc. Fixes imports that were `../` instead of `./`
Instead of DeferredWriter passes the WriterDelegator along in GenerationContext so generateProtocolTests can create the file only if any tests need to be written. This is alternative to smithy-lang@09b9956 from smithy-lang#360. It is going back to using writerDelegator like before (and picking the fileName inside the test generation logic, instead of in DirectedTypeScriptCodegen.
The 2 SmithyBuildPlugins have duplication, which can be reduced via refactoring Ran `yarn generate-clients -s && yarn test:server-protocols` in aws-sdk-js-v3 with this commit. Compared the generated ssdks with https://github.com/gosar/aws-sdk-js-v3/tree/f47b48a1eb1187657f489b4e041f979e72e0134d and found there were differences but only some moving around of code within some files.
Given the plugins have moved to DirectedTypeScriptCodegen
The generator does not produce any .tsx files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve the rebase
The logic of `writeAdditionalFiles` was moved into `customize` as a follow up on the discussion here: smithy-lang#548 (comment)
Migrating the code generator to use Smithy's new and recommended DirectedCodegen.
This PR is dependent on related change in smithy repo - smithy-lang/smithy#1237 and smithy-lang/smithy#1289 which haven't been released yet. Once they are released, this PR can be merged into
main
.Testing by regenerating based on new code
Clients
yarn generate-clients && yarn test:protocols
AWS SDKs, Generic client (under
/private/aws-echo-service
) and Protocol tests (under/private
) regenerates without any diffs.SSDKs
yarn generate-clients -s && yarn test:server-protocols
Generated SSDK isn't committed to
main
, but see the differences based on a baseline that was committed to a branch just to enable this comparison pre/post DirectedCodegen - gosar/aws-sdk-js-v3@generated-ssdk-Jun28...gosar:aws-sdk-js-v3:generated-ssdk-Jun28-directed-codegen. The base for this isgenerated-ssdk-Jun28
branch which is based on smithy-1.21.0 and smithy-typescript main branch. And the diff is againstgenerated-ssdk-Jun28-directed-codegen
which is based on smithy/main (unreleased) and smithy-typescript/directed-codegen branch (this PR branch).As seen in the link, there are 2 types of changes.
yarn test:server-protocols
is actually broken because of some changed. But this will have to be taken up separately. It does not affect the DirectedCodegen migration.Misc
I made and committed some PRs independently already to reduce the diffs in this PR.
#541
#542
#544
#545
#547
#551
#559
#564
The code has a few TODOs and refactoring that I can be taken up separately. But at this point, the generator via DirectedCodegen is functionally equivalent to before.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.