-
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
(aws-core): Aspects are not visited if added via module #18921
Comments
I've also run into this. Worth noting too that I think this wasn't introduced with v2 but at some point later into v2's lifecycle. This was working after we migrated to v2, but broke at some point during a v2 upgrade. |
When construct libraries are purposely symlinked (as opposed of collectively `npm install`ed), depending on how this is done they may end up with multiple copies of `aws-cdk-lib`. If that happens, Aspects from a different `aws-cdk-lib` copy than the one providing `App` will not be applied. The reason is the use of `Symbol('...')` instead of `Symbol.for('...')` to keep the list of aspects on the construct object. - The first version creates a unique symbol per library, while adding a naming hint. - The second version deduplicates: all symbols with the same naming hint will receive the same symbol. The second version is necessary to make sure that different copies of the `aws-cdk-lib` library store their aspects under the same key. Fixes #18921, #18778, #19390.
When construct libraries are purposely symlinked (as opposed of collectively `npm install`ed), depending on how this is done they may end up with multiple copies of `aws-cdk-lib`. If that happens, Aspects from a different `aws-cdk-lib` copy than the one providing `App` will not be applied. The reason is the use of `Symbol('...')` instead of `Symbol.for('...')` to keep the list of aspects on the construct object. - The first version creates a unique symbol per library, while adding a naming hint. - The second version deduplicates: all symbols with the same naming hint will receive the same symbol. The second version is necessary to make sure that different copies of the `aws-cdk-lib` library store their aspects under the same key. Fixes #18921, #18778, #19390, #18914
|
What is the problem?
We have been migrating to CDK v2 and noticed our Aspects were not visited during a
cdk synth
. Tracking it down, we found that Aspects are visited if they are added in the app code but remain unvisited if added in library code.Reproduction Steps
Overview of Steps
mylib
andmyapp
projects in each CDK Framework versionmyapp (v1)
./v1/myapp/bin/myapp.ts
./v1/myapp/lib/myapp-stack.tst
mylib (v1)
./v1/mylib/lib/index.ts
Expected output of
cdk synth -q
:myapp (v2)
./v2/myapp/bin/myapp.ts
./v2/myapp/lib/myapp-stack.tst
mylib (v2)
./v2/mylib/lib/index.ts
Unexpected output of
cdk synth -q
:What did you expect to happen?
Expected to see identical output from the
cdk synth -q
commands of the v1 and v2 apps.For both projects, specifically,
What actually happened?
The following message was not seen.
Meaning, the Aspect added to the Stack in the library code was not visited during the
cdk synth
CDK CLI Version
2.12.0 (build c9786db)
Framework Version
2
Node.js Version
v14.17.1
OS
Mac OSX 12.1
Language
Typescript
Language Version
~3.9.7
Other information
For these reproducible steps, I used
cdk init lib --language typescript
andcdk init app --language typescript
to generate the both sets of projects. I then edited the v1 projects to use CDK v1 by changing the package.json dependencies, removing the node_modules folders, migrating the code itself, and running yarn build and link. I can provide the entire directory structure if it would help.The text was updated successfully, but these errors were encountered: