https://pulumi.com logo
#typescript
Title
# typescript
w

worried-city-86458

09/18/2019, 9:20 PM
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
c

clever-sunset-76585

09/18/2019, 10:04 PM
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.
🍺 1
w

worried-city-86458

09/18/2019, 10:19 PM
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. 😛
@white-balloon-205 does Pulumi track the latest TS quite closely?
w

white-balloon-205

09/19/2019, 12:10 AM
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.
w

worried-city-86458

09/19/2019, 12:20 AM
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.
c

clever-sunset-76585

09/19/2019, 12:36 AM
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.
t

tall-librarian-49374

09/19/2019, 6:30 AM
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?
c

clever-sunset-76585

09/19/2019, 5:16 PM
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.