aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.56k stars 3.87k forks source link

core: Provide visibility into the exports CDK implicitly creates #31582

Open dleavitt opened 5 days ago

dleavitt commented 5 days ago

Describe the feature

The CDK should provide some way for users to identify automatically-created exports.

Background

CDK has a feature where, when one stack ("child") references a resource from another stack ("parent"), it'll automatically create an export in the parent stack.

This has a major catch, discussed at length in the documentation and elsewhere on the internet, which is that it effectively creates a circular dependency between the two stacks. If you stop using the resource in the child stack, the cdk will try to remove the implicit export from the parent, deadlocking deployment until you figure out what was being implicitly exported and explicitly export it via exportValue or similar.

These implicit exports are a rather leaky abstraction, so it seems important to provide developers better visibility into the dependencies between stacks, especially implicitly-created ones.

Use Case

Proposed Solution

The code that creates the implicit exports is here: https://github.com/aws/aws-cdk/blob/febce9d8ae99e237d878d862877e4133f1adbce9/packages/aws-cdk-lib/core/lib/private/refs.ts#L195-L212

This code just calls exportValue with a single argument on the parent stack, indistinguishable from a similar call in application code. To be able to distinguish these implicit ones, I'd suggest either:

Either option would allow end-user tooling to distinguish between implicit and explicit exports. Both options seem backwards compatible and low-effort to implement.

Related, higher-effort, ideas:

Other Information

Editorial/general feedback: the code that controls this is relative simple, but it's buried in such a way that an end user can't really customize its behavior without forking the repo. This style of defensive programming seems to be pretty universal in the CDK codebase. I'd suggest that while minimizing API surface area like this is critical in the context of a large organization, it's not a good fit for open source.

There's no way to anticipate all the use-cases, so you should lean towards making things more hackable and thereby enable users to solve their problems in application code, rather than having to file tickets like this asking you to do it. ❤️

Acknowledgements

CDK version used

2.154.1

Environment details (OS name and version, etc.)

Mac OS 14.3

pahud commented 2 days ago

Thank you for your use case. Please help us prioritize with 👍 and we welcome more inputs in this thread.