This message was deleted.

Ah, I remember having that same issue with ESBuild. ESBuild produces an incompatible translation with the pulumi protobuffers in the SDK. My solution was to add an ESBuild transform to replace

window

with another identifier, I can't remember which.

hmm I’ll have a look into that… but

this

is already present…

The identifier is autogenerated by protobuf, probably for compatibility, but as you've noted it breaks when bundled.

for the minified version 😉

sed -i -e "s/window||d2e||self/d2e/g" path/to/index.js

Hello again Christian! I saw your comment on a related issue, I’ll follow up there too. I just wanted to give you a quick explanation to unblock you, but I’m trying to disconnect from this Slack over the weekend to keep a nice work-life balance for myself. To work around the error you’re getting, you still need to have the Pulumi SDK installed. When Pulumi boots, it looks for

@pulumi/pulumi/cmd/run

and executes that file, which is the entrypoint for NodeJS execution. You can bundle your program with ESBuild, but you still have to have

@pulumi/pulumi

installed unbundled so we can boot the runtime itself.

I tried that... it complains about other missing packages then 😞

The issue that you commented on would let us tree-shake out most of the code in

@pulumi/pulumi

— e.g. automation api, tests, etc. But we will always need some entrypoint into the NodeJS runtime. One other solution I’ve thought of is to install the runtime with the other language plugins — located at

$PULUMI_HOME/bin

. Then, user programs would be able to fully bundle.

that sounds like a good idea! we're using nix to build most of our stuff...

Nice! I’m a nix fan from afar — I don’t know virtually anything but I use

nix profile install

to grab most of my CLI tools lmao

I tried that... it complains about other missing packages then

I believe I got this to work in the past. I might look again at #10210 over the Christmas break. I want to try bundling with SWC if I can, hoping for a performance improvement. If there’s no perf improvement, I doubt we’d ship the change. I’ll also make a note to open an issue about decoupling the NodeJS runtime from the installed

@pulumi/pulumi

package (moving the runtime into

$PULUMI_HOME/bin

). It’s possible that has to wait until v4.0 since it could be breaking. I’m not sure what other languages do. I think Python is the same, which makes me think maybe all of our languages are the same. As an aside, I’ve also looked int minifying (but not bundling!) providers code. If you’re using e.g. AWS Native, the Node code for AWS Native is not minified. (We don’t want to bundle it because then using an S3 bucket would import every single AWS resource, which would kill performance). I figured if we minify the providers, then we’d improve performance (I was also able to preserve source maps after minification, so debugging doesn’t suffer). However, I found that the minified code produced by SWC is slower than unminified code produces by TSC. I’ve got a few bugs in my analysis, but that’s where I got hung up. (More info here.) Curious to hear your thoughts on this! Signing off for the weekend! Good chatting with you! I’ll follow up on the issue tomorrow.

thanks!

Gotcha. I'll take a look and see if I can get bundling of the runtime working. Suppose you bundle your program, then delete

node_modules

, then

npm install @pulumi/pulumi

. That should pull in the remaining dependencies, right? e.g.

grpc/grpc-js

that might work yes, will give it a go. for now we are just bundling our own code and keeping node_modules as external

Nice! One of my collegues wrote a flaketo install

pulumictl

and I think Pulumi itself?

we need pulumi to step up a little in the nix community and ensure the packages are kept up to date… just doing brew isn’t going to cut it I’m afraid

Here's the flake to install

pulumictl

. https://github.com/t0yv0/pulumi-nix-devenv-flake

nix is a quirky language, simple, but worth learning. nix is powerful and very useful.

Have you played with any of the tools/languages built on top of nix? Like Riff or Flox? Another forthcoming weekend project for me 😅

I'm sticking to straight Nix for now. Unfortunately in case of Pulumi there's two areas were I run into Nix trouble - it's Node and Python. I think it's a bit more than just a steep learning curve, the interaction with Node and Python ecosystems is not so streamlined with the Nix model I think. In case of Node,

npm ci

directives like to go and issue HTTP requests breaking Nix sandboxing model - there was at least one program I've ran into that I could not package at all. And in the case of Python,

venv

is probably a bit better behaved but still has some scary interactions with the Nix model especially when native dependencies are involved, which may have been installed systemwide.

we’ve also taken the pulumi-bin package, made it our own and stripped out a few things. but we use it in anger because it ensures deterministic builds, I also use it to package node applications using a simple derivation, as long as there is a package.json and yarn.lock involved it won’t have side-effects and nix doesn’t moan.

@cold-toothbrush-60276 here's a WIP PR to bundle the NodeJS runtime. It doesn't get you all the way to bundling user programs, but it should let you remove non-

@pulumi/pulumi

packages from

node_modules

(I tested this locally with success).