How does pulumi treat component resources, is it just that they are displayed as a single item in the plan? Or are there other differences?

The three main features of components are: 1. Logical structure which is displayed in update progress and other UI 2. Namespacing of resource names to ensure components can be composed cleanly and safely 3. Inheritance of defaults for many resource options - in particular the

provider

- so that these can be passed once to a component and automatically inherited by all children of that component. It looks like https://pulumi.io/reference/programming-model.html#components isn't yet clear on these three points - so I'll make sure we update that.

Perfect thank you. I have a suggestion (this may be a broader discussion to be raised on gh) - it would be nice to have something like a ComponentGroup class, with an API that allows components to be grouped without having to inherit ComponentResource. The main benefit being that it opens up more options in terms of patterns that can be used with pulumi. My specific need for it is I am writing wrapper code that follows the builder pattern and I want the builder to return a ComponentResource for the reasons you mentioned above. I've gone ahead and created a ComponentGroup class myself which works fine but perhaps it's something other developers would find useful. My thinking is the key benefit pulumi provides is that we can finally build our infra with code so it should allow for maximum flexibility with respect to which paradigms can be used with it.

Definitely would love to see more details on this proposal in a GH issue!

My thinking is the key benefit pulumi provides is that we can finally build our infra with code so it should allow for maximum flexibility with respect to which paradigms can be used with it.

Totally agreed, and we've seen quite a few patterns for constructing components. In general, I haven't seen any specific API design patterns that can't be built on top of the ComponentResource abstraction (perhaps just as an implementation detail internal to the API) - but would love to see details on the kind of API design that doesn't currently fit into this model and what we could do to enable it.