chore(kms): cross-stack usage detection depends on NPM tree #15580
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KMS keys try to be smart about not generating impossible dependencies between multiple stacks, which CodePipeline takes advantage of for its support stacks. However, because the logic that tests for this case has an `instanceof Construct` in its code path, if there are ever multiple copies of the `constructs` library in the NPM tree the test will fail, and the resulting error will be very confusing. This situation can arise when people flip back and forth between CDK v1 and v2, because `package-lock.json` will contain half-baked dependency trees; people will be looking at their code but the issue will be in invisible state. Be more liberal in detecting that a construct is, in fact, a construct to get around this.
|
|
ericzbeard
reviewed
Jul 15, 2021
packages/@aws-cdk/aws-kms/lib/key.ts
Outdated
| * multiple copies of the `constructs` library on disk. This can happen | ||
| * when upgrading and downgrading between v2 and v1, and in the use of CDK | ||
| * Pipelines is going to an error that says "Can't use Pipeline/Pipeline/Role in | ||
| * a cross-environment fahsion", which is very confusing. |
eladb
reviewed
Jul 15, 2021
packages/@aws-cdk/aws-kms/lib/key.ts
Outdated
Comment on lines
688
to
694
| function isConstruct(x: any): x is Construct { | ||
| const sym = Symbol.for('constructs.Construct.node'); | ||
| return (typeof x === 'object' && x && | ||
| (x instanceof Construct // happy fast case | ||
| || !!(x as Construct).node // constructs v10 | ||
| || !!(x as any)[sym])); // constructs v3 | ||
| } |
There was a problem hiding this comment.
This is how production software looks like!
There was a problem hiding this comment.
Should we move this to the constructs library? Feels like it might be a better place to put this code, no?
There was a problem hiding this comment.
For sure. Don't forget to add it to both versions :)
eladb
approved these changes
Jul 15, 2021
|
Thank you for contributing! Your pull request will be updated from master 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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
TikiTDO
pushed a commit
to TikiTDO/aws-cdk
that referenced
this pull request
Aug 3, 2021
KMS keys try to be smart about not generating impossible dependencies between multiple stacks, which CodePipeline takes advantage of for its support stacks. However, because the logic that tests for this case has an `instanceof Construct` in its code path, if there are ever multiple copies of the `constructs` library in the NPM tree the test will fail, and the resulting error will be very confusing. This situation can arise when people flip back and forth between CDK v1 and v2, because `package-lock.json` will contain half-baked dependency trees; people will be looking at their code but the issue will be in invisible state. Be more liberal in detecting that a construct is, in fact, a construct to get around this. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
hollanddd
pushed a commit
to hollanddd/aws-cdk
that referenced
this pull request
Aug 26, 2021
KMS keys try to be smart about not generating impossible dependencies between multiple stacks, which CodePipeline takes advantage of for its support stacks. However, because the logic that tests for this case has an `instanceof Construct` in its code path, if there are ever multiple copies of the `constructs` library in the NPM tree the test will fail, and the resulting error will be very confusing. This situation can arise when people flip back and forth between CDK v1 and v2, because `package-lock.json` will contain half-baked dependency trees; people will be looking at their code but the issue will be in invisible state. Be more liberal in detecting that a construct is, in fact, a construct to get around this. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
KMS keys try to be smart about not generating impossible dependencies
between multiple stacks, which CodePipeline takes advantage of for
its support stacks.
However, because the logic that tests for this case has an
instanceof Constructin its code path, if there are ever multiple copies of theconstructslibrary in the NPM tree the test will fail, and theresulting error will be very confusing.
This situation can arise when people flip back and forth between
CDK v1 and v2, because
package-lock.jsonwill contain half-bakeddependency trees; people will be looking at their code but the issue
will be in invisible state.
Be more liberal in detecting that a construct is, in fact, a construct
to get around this.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license