Enable a variety of Dockerfile.*-driven custom builds

[benjamn]

This branch records my progress towards making custom builds of Deno easily shareable via Docker.

Docker is not the only way to use this fork of Deno. You can, of course, build the project from source locally, and the deno-setup.sh and deno-build.sh scripts are good references for how to do that (at least on a UNIX system).

You can find the Docker-based commands for building these four tagged images in the docker-build-all.sh script:

• benjamn/deno:unmodified-builder (heavyweight compilation, plain)
  • benjamn/deno:unmodified (derived from builder)
• benjamn/deno:async-context-builder (heavyweight compilation, custom fork)
  • benjamn/deno:async-context (derived from builder)

If you have Docker installed and running, you can fire up the Deno REPL using these images by running either of the following commands:

docker run -it --rm benjamn/deno:unmodified repl
docker run -it --rm benjamn/deno:async-context repl

With both commands, the -it is necessary for an interactive persistent shell, and --rm helps clean up the images after each one exits. The logged in user is named deno, and does not have root or sudo access, but does have a /home/deno home directory. The default working directory is /deno, which can be overridden using the -v $(pwd):/deno flag, as in

docker run -it --rm -v $(pwd):/deno benjamn/deno:async-context test --allow-read some.tests.ts

where some.tests.ts is a file in whatever local directory docker run was executed in… on the host computer! This directory-mounting ability is remarkably powerful here, since it allows an Ubuntu-built deno binary to read/process/write files checked out on, say, Mac OS X, without me having to publish a bunch of binary builds for different platforms.

With the :async-context image, you'll find a prototype implementation of the AsyncContext proposal available globally, in case you want to play with that. I hope this system proves flexible enough to prototype other ECMAScript and TypeScript extensions as well as AsyncContext.

[benjamn]

With this pattern of multi-stage builds, this final Dockerfile can pick out the single static deno binary file from the builder image, and users of this image only need to pay for downloading that binary (about 89MB on top of the Ubuntu base image, which is even less). Thanks to @ryan-williams for this crucial tip!

[benjamn]

After an epic optimization ride over the last few days (25GB+ Docker image size whittled down to 162MB; see below), my final image ended up a little smaller than the official denoland/deno image, though I'm sure I'm not comparing apples to apples here, and the main reason this works so well is because, as the Deno installation docs make clear, deno is a single static binary:

Deno works on macOS, Linux, and Windows. Deno is a single binary executable. It has no external dependencies.

This means we need literally nothing else from the build besides the binary, which is amazing/convenient.