aws-cdk-lib: automatic dependency creation for L1 constructs

[alisade]

Describe the feature

When an L1 construct is pointing at another (L2?) construct cdk should automatically create the dependency example below:

Use Case

      const crawler = new glue.CfnCrawler(
        this,
        `GlueCrawler-${dynamoDbTableName}`,
        {
          databaseName: dbName,
          role: crawlerIamRole.roleArn,
          targets: {
            dynamoDbTargets: [{ path: dynamoDbTableName }],
          },
        },
      );

here the glue construct depends on the IAM role, even though its pointing at the role Arn we still need to create a manual dependency for the IAM role to be created first as below

crawler.node.addDependency(crawlerIamRole);

CDK should see this reference and create the dependency under the hood.

This is very similar to how terraform behaves as well. Terraform sees a dependency and makes sure the dependent resource is created first.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.150.0

Environment details (OS name and version, etc.)

MacOS 15.4.1 (24E263)

[pahud]

Hi @alisade,

Thanks for submitting this feature request!

You're absolutely right that logically, when you pass crawlerIamRole.roleArn to the role property of CfnCrawler, there's an implicit dependency – the crawler needs the role to exist first.

The core of your request is about translating this logical dependency into an automatic CloudFormation DependsOn relationship within the CDK framework. Currently, the CDK primarily creates these DependsOn relationships based on explicit node.addDependency() calls or certain structural relationships in the construct tree.

The challenge lies in the timing and mechanism of dependency detection. The value crawlerIamRole.roleArn is initially an unresolved Token. The CDK's dependency graph construction phase often occurs before these Tokens are fully resolved into concrete values. As a result, the framework doesn't automatically infer the dependency solely from inspecting the role property's assigned Token value during this phase. You can see the logic for handling explicit dependencies in the addDependency function.

Implementing automatic dependency inference based on property values (Tokens) would require enhancements to how the CDK handles Token resolution and dependency graph construction, potentially by analyzing resolved values later in the synthesis or tracking Token origins more closely.

This remains an interesting proposal that could significantly simplify dependency management. We encourage the community to discuss this further and welcome contributions. If you or someone else is interested in exploring an implementation, a pull request would be the best way to move this forward.

Thanks again for the suggestion and the clarifying question! I'll bring this up to the team for visibility as well.