This message was deleted.

I think it’s a mix. From the perspective of the CDK constructs you are using, it is still a “heavy weight” thing in the sense that it marks the boundary of the CDK compilation. From the perspective of the outer Pulumi code, it’s “just another Pulumi component”. But you typically want to keep that CDK island quite coarse grained because imperative CDK operations only impact things within the CDK island (you can’t create one pulumicdk Stack, then another Pulumi resource, then use an imperative CDK operation to grant permissions to something defined in the pulumicdk Stack - since it will already be deployed at the boundary of the pulumicdk Stack). For CDK library authors, I’d generally encourage not using pulumicdk directly - and just leaving it to your users to be able to consume your constructs from Pulumi via pulumicdk Stack - much like they consume your constructs from CDK using g awscdk Stack.

What about for the Pulumi YAML use-case? In that case, I assume it's better for me to provide an interface that is designed for Pulumi's Inputs and Outputs? One that wraps Stack?