I'm new to JS/TS but it seems to me what is needed is "top-level await" support - I just want to await something in

index.ts

I’m new to JS/TS but it seems to me what is needed is “top-level await” support

Yes. This is tricky to do without first-class language support. Unrelated to Pulumi, but it is also one of the goals for

deno

a new framework being built by Ryan Dahl. https://github.com/denoland/deno/issues/471 has some links to relevant TS issues worth a read.

Thanks for the links Looks like some nice features, including top-level await, will drop in TypeScript 3.7: https://github.com/microsoft/TypeScript/issues/33352 Will make me feel more comfortable, as a C# developer. 😛

The

@pulumi/pulumi

package pulls in

"typescript": "^3.0.0",

, so will get the latest release of TypeScript at the time it is installed, and can be updated to any version of TypeScript that you would like to use. For top-level-await, the bigger problem I believe is that Node would need to support it in it's core module loader. I don't believe there is any near term plan for that (the linked issue is for Node REPL support - which is not sufficient). (random aside - I drove the async/await proposal in the TC39 standards body 5 years ago, and this was a topic that was discussed at the time - most of the same issues still apply - https://github.com/tc39/ecmascript-asyncawait/issues/9 ). Now - all that said - the Pulumi programming model in general really encourages/enables a mode where you shouldn't in general need to use await at all. The

Output

type is designed to allow you to pass around data instead of having to manually write asynchrosnous control flow. I'd be interested in seeing any cases where you feel like you need top-level await in Pulumi. In general - that shouldn't be necessary.

Kudos. Love your work! It mainly came up because I initially saw something returned a promise and I naturally wanted to await it, only to realize I couldn't, and subsequently finding out about Pulumi use of deasync and lift, which meant I didn't have to await it anyway, albeit with potential issues as pointed out.

From personal experience, often times I find that I need to use async/await for doing non-Pulumi things in my Pulumi app. But I have been lucky so far that there are sync versions available that allowed me to use those instead of doing something crazy.

doing non-Pulumi things in my Pulumi app

You can always declare an async function and use it in one of the

apply

calls, right?

That’s what I do when the “non-Pulumi” thing is something related to a resource. I can’t recall an example right now. The other solution I have followed is to wrap that non-Pulumi thing in a

ComponentResource

, that way the non-Pulumi thing acts as a resource and hence plays well with

Outputs

and such.