elm.lock versus a pinned Docker image for enforcing identical Elm compiler versions

Direct answer

When identical compiler behavior is the primary constraint, a container image pinned by digest is the stronger default. elm.lock is not a compiler lock; it only fixes dependency resolution. A documented native compiler version is lower friction, but it is a request, not an enforcement mechanism.

What elm.lock actually pins

Confirmed behavior in Elm 0.19.x: elm.lock records the exact package versions and revision hashes resolved for your project. It does not record which compiler binary generated it, and Elm does not use the lock file to reject a version mismatch. Two machines with different installed compiler versions can read the same elm.lock and still produce different diagnostics or optimized output.

Likely guard: the elm-version field in elm.json plus an explicit CI check is the practical native defense. Treat any compiler-side rejection as version-sensitive and verify it against your exact patch release rather than assuming it is universal.

Why a digest-pinned container is stronger

A container fixes the compiler binary, its runtime, and the package tooling in one artifact. Tags such as 0.19.1-slim are mutable, so pin by digest and update deliberately. The container also makes the toolchain explicit: contributors do not need to replicate a native install procedure.

Verifying the container is not leaking host state

To prove host-level dependencies are not altering the build:

1. Pin the image digest and run the same digest on two different hosts.
2. Use a fixed ELM_HOME inside the container so package caches do not drift.
3. After dependencies are cached, run with --network none to confirm no registry access is required for the build.
4. Build in clean containers with different host working directories and users, then compare elm make --optimize artifact hashes.

Any hash difference should be investigated before blaming Elm.

When a documented native version is enough

For pure Elm projects with no external bundlers, code generators, or native tools, elm.lock plus an exact compiler version can approach container determinism because host system libraries rarely affect elm make. It still depends on every contributor running the same compiler build. A CI check makes drift visible:

test "$(elm --version)" = "0.19.1"

This fails on mismatch but does not prevent a local contributor from building with the wrong binary.

The one diagnostic that changes the advice

Do you have non-Elm build steps? If your pipeline includes a JS bundler, code generation, a native tool, or a platform-specific package, those live outside elm.lock and can break reproducibility. In that case, containerizing only the Elm compiler is insufficient; pin the entire toolchain in the same image or CI job.