This message was deleted.

I consider that an anti-pattern. Configuration for a component should be passed into it in all cases. It's the only way to ensure proper testability.

@little-cartoon-10569 to prevent confusion, I wouldn't force this to be single/only way of configuring a component. If component config comes from the stack config, I would provide an additional function next to my component, like

getComponentConfig()

which in its implementation would e.g. call

pulumi.getConfig('my-component-name').require(...)

(or

requireObject

)

Ok. Still, it won't work in a unit test, where you can't call

pulumi.getConfig()

at all, because you're not in a Pulumi runtime.

But the call to

pulumi.getConfig()

wouldn't be inside my component implementation, this would be in the

getComponentConfig

function which is next to my component class.

So in your test code, you'll need to implement

getComponentConfig()

to inject values?

What you are hinting at is this:

config = {
  key: value
}
component = new package.ComponentResource('name', config)

What I am hinting at is this:

config = package.getComponentConfig() // <- only this reads from stack config with a separate key
component = new package.ComponentResource('name', config)

So you see that

package

exposes two items: the config helper function and my component resource, which still is decoupled from how config is passed. Actually, it exposes 3 items: I missed the

args

interface type, e.g.

ComponentArgs

Yes, that sounds useful. I don't currently ever need to do that, since the config is always project/program specific. For example, in some cases the component's config would be hard-coded in the program; in some cases it would be derived from an existing config value. If the dev was expect to provide a well-known set of config values for my component, it implies that each program that uses the component would have to document any deviations from that well-known config structure.

True, but in our setup, we distinguish between "real" config and info which comes from the environment. We have a standard approach to that.

Then this is a good solution. The namespace is owned by the component (or at least, the library that provides the component). That makes sense.

What you're describing sounds like the way dotnet configuration works, where libraries can read the config via the passed config root, and access the part scoped to their specific name.