dontlaugh / packer-provisioner-deno Goto Github PK

There is a known issue with compiling TypeScript code (aka your deno scripts) on machines that only have a single CPU denoland/deno#2124

For your cloud provider's builder stanza, work around this by selecting an image size with at least 2 CPU/vCPU.

$ doctl compute size list

On digitalocean, the cheapest droplet with 2 CPUs is $15/mo and has slug identifier s-2vcpu-2gb.

Since we bundle scripts locally, then upload and execute them remotedly (#4), there is a chance that a version mismatch can cause execution to fail.

The deno installer script allows specifying a version

curl -fsSL https://deno.land/x/install/install.sh | sh -s v0.27.0

We add a config parameter that allows specifyng this during installation.

We might also consider parsing the output of deno --version locally, and automatically trying to match it up.

Bundling support is almost here. Test it out and upload bundles into virtual machines and containers for bigger, more complex provisioning use cases.

The idea here is to avoid fetching and compiling code on the target machine, so we will require (by default), a local deno installation. This will speed up repeated packer builds since unchanged bundles could be cached and uploaded right away (instead of fetching/recompiling every time on the clean target environment).

We should, of course, allow overriding this behavior so that deno on the target machine can fetch and compile code. Not everyone who runs packer will want or be able to install Deno locally. But I think the common case will benefit from local compilation.

Besides, I want to figure out the whole ship-compiled-code thing ;-)

Deno usually needs to be delivered to the target platform. We can do this with:

• uploading a local build (uncommon, probably for Deno devs only) with local_deno_bin
• curl-to-shelling the installer script

The latter method means we need to test for curl on the system, and if it isn't present, install it. If the system has a package manager, it's likely that curl will be there.

Let's try to stick to the standard installer script, and if we find a bug in it on a specific platform, contribute the change upstream (if it's not too esoteric and complex).