-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix: importing aws-cdk-lib
is slow
#23813
Conversation
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
aws-cdk-lib
is slow
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
Exempted tests and integ-tests as no change and passing tests is a sign of this working as expected. |
Running a full build as |
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.
Lovely hack-fix! 😍
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Leaving the do not merge label on until he have decided if this is a good idea. |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Is there a chance this PR has broken an es6 style import?
|
PR #23813 made imports lazy, but in the resulting code, Nodejs no longer recognizes the exports when importing `aws-cdk-lib` from an ESM module. Apply a transformation on the source that makes Nodejs detect the exports again.
Thanks @mikolaj-w-provectusalgae We are working on a fix. |
PR #23813 made imports lazy, but in the resulting code, Nodejs no longer recognizes the exports when importing `aws-cdk-lib` from an ESM module. To solve this, vend two different index files: one for use by CJS imports, one for use by ESM imports. ESM modules will still try to load the entire library, so they don't benefit from the speed boost. This is unavoidable: we tried a more complex method that forced ESM to recognize the lazy module references anyway (by tricking the backwards compatibility lexer), but ESM did not experience a speed boost, indicating that it was crawling the entire module irrespective of the submodule accessor's laziness. So, we are opting for the simpler solution of vending two index files instead. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
PR #23813 made imports lazy, but in the resulting code, Nodejs no longer recognizes the exports when importing `aws-cdk-lib` from an ESM module. To solve this, vend two different index files: one for use by CJS imports, one for use by ESM imports. ESM modules will still try to load the entire library, so they don't benefit from the speed boost. This is unavoidable: we tried a more complex method that forced ESM to recognize the lazy module references anyway (by tricking the backwards compatibility lexer), but ESM did not experience a speed boost, indicating that it was crawling the entire module irrespective of the submodule accessor's laziness. So, we are opting for the simpler solution of vending two index files instead. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@mikolaj-w-provectusalgae Can you confirm if v2.62.1 fixes this for you? |
It is partially fixed. The project can be synthesized and deployed, but the tests fail. I'll do some digging in Jest's configuration and see what's wrong.
Jest config {
preset: 'ts-jest/presets/default-esm', // or other ESM presets
testEnvironment: 'node',
roots: ['<rootDir>/__tests__'],
testMatch: ['**/*.test.ts'],
moduleNameMapper: {
'^(\\.{1,2}/.*)\\.js$': '$1',
},
transform: {
'^.+\\.tsx?$': [
'ts-jest',
{
useESM: true,
},
],
},
}; |
I guess |
Makes sense. Could you try adding a Relevant section would then look like this: {
// ...
"exports": {
".": {
"types": "./index.d.ts", // <---- this is new, needs to be first entry
"import": "./index.js",
"require": "./lazy-index.js"
},
// ...
} |
Yep. That's it! test, synth and deployment pass. |
Sweet! Thanks for helping out. We'll get the fix out asap. |
Thanks for your quick response! |
@mikolaj-w-provectusalgae v2.62.2 is released |
Fixes slow import of top-level aws-cdk-lib.
At the very end of the build, the compiled
index.js
file is replaced with a version optimized for import performance.Instead of loading submodules directly at the top level, exports are defined as getter functions.
This way they will only be required when actually imported from
aws-cdk-lib
.Improves AWS CDK app performance by ~400ms.
Background reading: https://medium.com/trabe/exporting-getters-in-commonjs-modules-dd8f98b7d85e
All Submissions:
Adding new Construct Runtime Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license