[feat] Deno TypeScript runtime support

[brandonkal]

I'm going to throw this one out there because it is a natural fit for configuration code.

Pros:

• No package manager. Let's face it. It's annoying to download a bunch of modules just to "Hello World" a Pulumi Program. For simple things, one will just reach for YAML instead. Because Deno uses standard HTTPS imports you can just run a file and forget about packages.
• You can run via URL. deno https://example.com/a-pulumi-program.ts could be the Pulumi equivalent of kubectl apply -f https://example.com/some-manifest.yaml
• Easier to lock down (i.e. a Deno program cannot read environment variables by default so config is more hermetic). It is still an option though if the user specifies.
• Simple to support.

To support Deno Pulumi would need to

• Generate TypeScript code that includes the file extension in the imports.
• Ensure TypeScript code doesn't access modules variable and other legacy CJS things.
• Distribute code on a nice HTTP endpoint or let raw.githubusercontent.com perform that function. So an import could be

import * as pulumi from 'https://pulumi.com/pulumi@1.4.5/mod.ts'

• The pulumi CLI would handle installing plugin binaries as there is no postinstall scripts like npm.

[pgavlin]

cc @lukehoban

[gabemeola]

This would be great, and more easily allow for mixing languages (say Java for the server and Typescript for Pulumi infra) without needing to pull in the whole NodeJS ecosystem.
I think #3901 might solve this a bit better.

[Graham-Beer]

Wanted to add my support for Deno as well. Much more light weight that NodeJS and makes use of the new Javascript features under the hood where NodeJS doesn't. Built in support for TypeScript as well is a much added bonus.

[brandonkal]

Closing as I no longer use Pulumi

[leezen]

Re-opening as the issue is still something the community wants.

[pecigonzalo]

I think Deno greatly lowers the barrier to entry for Pulumi TS as you dont have to bring all the "noise" of the JS/TS ecosystem.

[nuvanti]

We are a Deno shop, it'd be great if you could add Deno support.

[rafaribe]

What's the current state on this? Any progress?

[gaui]

Would love this!

[algoflows]

The waited has been so long that the thumbs have gone down from 40 to 7 🥲

[06kellyjac]

The original is at 42 👍

[ProdigySim]

Has anyone tried to use this with one of the deno-friendly CDNs described in their docs?

[pecigonzalo]

I've tried a while ago, and it did not work for me unfortunately.

…

On Thu, May 5, 2022 at 6:48 AM Michael Busby ***@***.***> wrote: Has anyone tried to use this with one of the deno-friendly CDNs described in their docs ***@***.***/node/cdns#esmsh>? — Reply to this email directly, view it on GitHub <#3838 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACLS7CJME4FBMGOANYKOY2DVINHJNANCNFSM4KNKNW5Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RobbieMcKinstry]

I've tried them recently too, and with little success.

[RobbieMcKinstry]

I think this is a really interesting issue. In my mind, the use case is pretty compelling. Deno is (arguably) less finicky than Node. I suspect it'd be a lot easier to distribute and manage than the Node runtime. I'm still coming up to speed on the Pulumi execution model; I'm keeping this issue in the back of my head while ramping up.

[CanRau]

Love to be able to just add a dependency via a URL instead of needing to go to the terminal install and then go back to what I was doing

Also publishing reusable code is so much nicer, no need for a registry just GitHub or some accessible URL, done 👍

[denizdogan]

Deno 1.25 makes it slightly easier to import modules directly from NPM, but even with that, I'm not sure how one would add a new "runtime" to Pulumi to use Deno instead of Node.js.

[RobbieMcKinstry]

Pulumi uses a supervisor process we call "the language host" to boot a gPRC served called "the language runtime". The language host, which is a program written in Go could, in theory, choose between a Deno and a NodeJS runtime. I believe we do this currently with Java, choosing between Maven, Gradle, etc. I believe there's prior art.

[Frassle]

I'm not sure how one would add a new "runtime" to Pulumi to use Deno instead of Node.js.

could, in theory, choose between a Deno and a NodeJS runtime.

Yeh I'm not sure if deno should somehow just be supported in the "node" runtime, or if this needs to be a whole new language runtime + package publishing system.

[RobbieMcKinstry]

Now that Deno supports (in beta) interoperability with NPM packages, I think Deno would be able to use the existing Node packages.
The Deno team is supposedly offering enterprise office hours for collaborators working on ecosystem improvements. If this is ever scheduled, that's probably a good first step before any code is written.

[pecigonzalo]

Deno NPM is out of beta. I think one of the core questions I have is how to indicate to pulumi up to use the Deno runtime. That way we can try and hook it up.

[RobbieMcKinstry]

@pecigonzalo Right now the architecture looks like this:

1. The pulumi engine launches a subprocess for the Language Host (a Go binary), which is responsible for initializing the Node process which actually executes user code. This is the Language Host.

2. The Language Host launches the Language Runtime, a Node program that wraps and executes the user code. This line specifies the Node module to launch. You'd need to edit locateModule(here) and other helper functions which use Node to inform the runtime.

3. Inside the language host, Node is used pretty heavily as well. Here's the link to the language host entrypoint, but most of the logic is in run.ts. Here's an example of a helper that might need to be tweaked.

One great improvement we could make is to put all uses of Node and NPM behind an interface so we could swap it out with an alternative (like Deno, for instance, or PNP).

[danielrbradley]

The biggest piece of work to support this would be reworking the core nodejs SDK. This utilizes various parts of nodejs's internal runtime for aspects like closure serialization.

The options I can see are:

1. Have separate SDKs for nodejs and deno
   • Create a fork of pulumi/pulumi's nodejs SDK for deno with closure serialization removed
   • Generate a dedicated deno SDK for each provider based on the new pu/pu SDK
2. Refactor closure serialization out from the core pulumi/pulumi nodejs SDK
   • Create a separate package for closure serialization (e.g. @pulumi/nodejs)
   • Make the core nodejs SDK a portable JS library (no nodejs dependency)
   • Providers which integrate with closure serialization directly (e.g. aws) moves this functionality into an extension package (e.g. @pulumi/aws-nodejs)

[runlevel5]

Deno now supports many NPM packages, for example aws-sdk, it would help the porting effort I believe.

[algoflows]

Is this still planned, what's the current status looking like? We're going deep into Deno now and hope to build a Pulumi provider for the Deno deploy service. We are also starting our startup on Deno and would love to keep a unified Deno TS only codebase with Pulumi written in Deno.

[guy-borderless]

Is this still planned, what's the current status looking like? We're going deep into Deno now and hope to build a Pulumi provider for the Deno deploy service. We are also starting our startup on Deno and would love to keep a unified Deno TS only codebase with Pulumi written in Deno.

I would also appreciate an update, my ts services are all deno