If we wanted to separate Pulumi resources over multiple files, to aid in organisation and readability, would the only way to do this be through creating Component Resources inside the project and then calling those, or is there an easier way? This is in C# specifically. I'm thinking of how in Terraform I could create resources in different tf files in the same folder and Terraform would merge them togther

i am using typescript but the idea is the same, essentially methods on static classes

I guess I don't understand.. you can already split your resources into different files just by making a new class file and referencing it in your pulumi program. I must be misunderstanding the question?

I always felt like this violated the principal of least surprise in terraform, you left a file hanging around and even though you didn't explicitly import it, it still applied and created things

ah. What @billowy-army-68599 said clicked. Yea to me that doesn't improve readability at all, in fact does the opposite

So the scenario I am thinking of is I am creating a number of Azure policies, these are long complex objects and it can be hard to find the particular policy you want to work on, so would be nice to separate them into files to improve the experience of working with them. Your point on just putting them in separate classes is probably correct, I'm still working on my C# knowledge!

I think your initial thought to use

ComponentResource

was correct, which has the added benefit of making them re-usable

Oh, this is interesting. I wasn’t aware of

ComponentResource

. Indeed, reading the docs, that seems to be the way to go. Up until now I realised this using custom classes. Thank you for the heads up @miniature-leather-70472 @bored-oyster-3147

just remember that with Component Resources you need to pass

Parent: this

to all of the child resources and at the end you need to call

this.RegisterOutputs(...)

Strictly, you don't need to set the parent: it is ok for a component resource to create top-level resources. It does violate the principle of least surprise though, and it breaks the intuitive ordering of dependencies. So it's strongly recommended.