worried-city-8645809/18/2019, 9:20 PM
clever-sunset-7658509/18/2019, 10:04 PM
I’m new to JS/TS but it seems to me what is needed is “top-level await” supportYes. This is tricky to do without first-class language support. Unrelated to Pulumi, but it is also one of the goals for
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.
worried-city-8645809/18/2019, 10:19 PM
white-balloon-20509/19/2019, 12:10 AM
package pulls in
, 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
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.
worried-city-8645809/19/2019, 12:20 AM
clever-sunset-7658509/19/2019, 12:36 AM
tall-librarian-4937409/19/2019, 6:30 AM
doing non-Pulumi things in my Pulumi appYou can always declare an async function and use it in one of the
clever-sunset-7658509/19/2019, 5:16 PM
, that way the non-Pulumi thing acts as a resource and hence plays well with