https://pulumi.com logo
Title
p

prehistoric-kite-30979

03/01/2022, 3:40 PM
When I add the following line to my inline program it complains with`Program run without the Pulumi engine available` :
const opts = { ...options.Azure('azure'), region: stack.region, resourceGroupName }
options.Azure is located in a separate TS package and does the following:
export function Azure(
    name: string,
    opts?: CustomResourceOptions,
    providerOptions?: ProviderOptions,
): AzureOptions {
    const subscriptionId = cfg.require('subscriptionId')
    const provider = new azure.Provider(
        name,
        {
            tenantId,
            subscriptionId,
            clientId: cfg.require('clientId'),
            clientSecret: cfg.requireSecret('clientSecret'),
        },
        providerOptions,
    )
    return {
        subscriptionId,
        provider,
        ...opts,
    }
}
I suspect it has something to do with it being in a separate package… any ideas?
l

little-cartoon-10569

03/01/2022, 7:59 PM
Where does
cfg
come from? If you call any Pulumi static method (e.g. getStack()) without having started the engine, you will see this error. Maybe you can change the order of imports? Or change
cfg
from being created inside the imported module to being passed into it from the main program?
If you have something like
const cfg = new pulumi.Config();
in your module, that's definitely not going to work. Do that in you main program and pass it to the module.
Even if it did work, you shouldn't do it. Coupling your module to the shape of your program's config file is not a good idea and will bite you in the future. App-specific config should be handled in an app-specific way, and passed into modules in module-specific APIs.
Which is exactly the model used throughout Pulumi, for example in their
args
and
opts
constructor parameters.
p

prehistoric-kite-30979

03/01/2022, 8:44 PM
yes, this was correct
I suspected this was the initial issue and fixed
but we were also calling getProject in a similar manner that I missed 🙂
Coupling your module to the shape of your program’s config file is not a good idea and will bite you in the future
We use it to override the default provider behavior and these are just helpers to build out the correct providers.
(and these are only ever called in projects and passed to modules/components)
l

little-cartoon-10569

03/01/2022, 9:06 PM
Even if you're doing for good reasons, it will help future you if you define an API for the non-default-provider-overrider function, and pass values into it. Allowing the function to call config.get is too much coupling and it is likely to cause problems in the future.
p

prehistoric-kite-30979

03/01/2022, 9:16 PM
I don’t disagree but I also dont want to have to type it out everytime ¯\_(ツ)_/¯