I think it’s worth mentioning Nix in this context as well. Nix builds run in a sandbox without any network access. So when you use Nix to build your Elm code, preventing network access at build time becomes a necessity rather than a “nice to have” for added stability and performance.
The announcement post for elm2nix makes some excellent points about what Elm could do better to enable Nix and other “build planning” software to work with the Elm compiler more easily:
[I]t would be ideal if there would be [an]
elm.lockfile or similar with all dependencies pinned including their hashesIdeally instead of committing [
versions.dat] to [the] git repository, one would be able to point to an url that would present [this] binary file pinned at some specific time - allowing it to always be verifiable with [an] upfront known hash.
I think Elm’s built-in package management provides a great beginner experience already! So with limited resources, I would say time is better spent on exposing information, documenting file formats, etc. This way, dedicated third-party build systems (like Nix or more conventional CI pipelines) can plug in easily once a project is ready to “graduate” from the exploratory phase, and the Elm core team can concentrate on other things.
How I use Nix in my Elm projects and Enabling pure Nix builds including elm-review & elm-codegen have more discussion of building Elm with Nix if folks are curious!