Maybe using a base of https://hub.docker.com/r/emscripten/emsdk would build faster and be easier ?

I appreciate it, and I started with that as the base actually! I abandoned it for a couple of reasons.

1. I thought it might make it harder to rev the version of the SDK we were using, and harder to experiment with versions of the SDK that weren't yet officially Docker-packaged yet. I don't know that this is a compelling goal, but it was part of the reason I abandoned it.
2. By starting with one of these standard devcontainers published by MS, we get not only node and Typescript (which are easy to install ourselves via the Dockerfile), but some of the other niceties that all of their VSCode Devcontainers get to make them easy to actually develop in, rather than just build in. Zsh, some other config niceties, etc. (https://github.com/microsoft/vscode-dev-containers/blob/master/containers/javascript-node/.devcontainer/base.Dockerfile) It seemed easier to standardize on a devcontainer and install the SDK rather than the other way around. But honestly, if I'm copying lines from Dockerfiles, I could flip it around. It just felt better to install the sdk into the container rather than depend on it as a base.

I will say that I wish Docker files were more composable, and that I could pick and that it was easier to "layer" portions of various public docker files, but I don't expect my "custom" portions of the Dockerfile to change much, other than perhaps the version of node or the emsdk we want to install. If we did want to make this more "composable", another option we have is to use a devcontainer that is one of the standard ones like typescript-node, expose docker to the container itself, and then expect it to be able to shell out to docker to perform the emcc compilation via a standalone emsdk container: docker run -it --rm -v $(pwd):/src --user emscripten --name emsdk emscripten/emsdk:2.0.15 bash) && docker exec -it emsdk make
I didn't like that approach though because I didn't like our development environment requiring/assuming that docker was present. In other words, I didn't want to rewrite our package.json scripts to assume that the docker command existed. As it stands, I've kept the docker thing highly recommended, but still optional. :)

The approach I've checked in worked great for me to standardizing our/my development environment, and installing the emsdk in the Dockerfile is "standard" enough to be obvious if it worked correctly. The two downsides I've seen with my approach after working with Github actions last night:

1. The container is currently built from scratch on each run which adds to the build time.
2. I ran into a bug where it couldn't execute the entrypoint.sh file to actually perform the make call. I assume I'm doing something trivially easy to fix. :)

I assume number 2 is easy to fix, so if we desired to fix number 1, we could either check in a built base version of this container to the Github registry and then pull it down as part of the build, or we could look into ways to cache the built docker container between runs.