Open michanto opened 4 months ago
Agree. But looking at this discussion
https://github.com/aws/aws-cdk/pull/28001#pullrequestreview-1731529704
What do you think about it? @tmokmss @go-to-k ?
Both could be supported by just adding isCfnElement to the existing?
Or you could adopt my Construct RTTI class
I agree that the current state is undesirable and should be fixed. However, I can't think of a way to make sure it's not a breaking change. I think the proposed change will not cause any problem, but there are so many cdk users in the world...
I have the same opinion with @tmokmss . (But I think it's probably OK.)
Even if you decide not to fix isCfnResource itself, you should fix the addDependency error on synthesis. That's definitely a bug.
Describe the bug
I created a construct class with a cfnResourceType property. I use that type to search for a CfnResource under the parent of that construct. But my non-CfnResource class is recognized as a CfnResource by the CDK because it has a cfnResourceType property! Wrong!
Expected Behavior
That would be a lot better because isCfnElement has an RTTI symbol property.
Current Behavior
Reproduction Steps
Possible Solution
Either this:
Or maybe:
Additional Information/Context
When I try to synthesize a stack with a fake CfnResource, I get the following error:
CDK CLI Version
2.120.0 (build 58b90c4)
Framework Version
No response
Node.js Version
10.2.5
OS
MacOS
Language
TypeScript
Language Version
No response
Other information
No response