This might be a dumb question but I haven't dove in deeply yet - how does Pulumi, when using JS/TS, interoperate with other modules for the purpose of code reuse? Is there an example out there? (My guess as to implementation is that internally there's a cross-module registry being provided to the module code that's updated when a resource's constructor is called, but I'm still getting my bearings; I just know that for us composable resources is a requirement.)

What exactly do you mean by "interoperate with other modules"?

@microscopic-florist-22719 I write a definition of cloud resources in a function within module A. I want to call that function within module B with parameters that specialize it for my use case there

I've got a local ts module shared by different pulumi programs. It just declares pulumi as a dependency, and the pulumi programs then npm install that local module. So it definitely works!

Okay. Pulumi JS/TS just uses normal JS/TS modules for this.

@microscopic-florist-22719 I got that far, I'm wondering how the backend behavior works

Providers and things are passed down via parent resources or a global top level resource (the stack it self I think)

i.e, if I export a function from A and it constructs Pulumi resources, those will belong transitively to the top level stack when that stack invokes

A.fn()

?

Yes.

Awesome. Perfect. Unsurprising. Thank you. 🙂

We generally use actual

dependencies

(to avoid version constraints/multiple instances of

@pulumi/pulumi

in the runtime)

It does--we go out of our way to make this work

Aah. So if your developers are, cough cough, a little less careful, would peer dependencies be a good idea?

Ideally the

@pulumi/pulumi

module will handle this situation gracefully and you should still be able to use real

dependencies

, but

peerDependencies

should unwedge you if we have bugs 🙂

Yeah - I have written my share of plugin architecture JS, hence the question

👍