Building a case for Elm Bazel Rules

Elm currently does not have any Bazel Rules publicly available, and as such if a company or individual wanted to migrate to Bazel for building even the non-Elm parts of their products, Elm code would have to be left out, or use Bazel Rules specially implemented by said company or individual.

I work with a company called Tweag I/O, which has already created Bazel Rules for Haskell. At Tweag, and in the codebases of our clients, Bazel has come in handy as a fast, language-independent build system, especially when there’s a whole lot of code involved. We have multiple Elm enthusiasts at Tweag, including myself, and are looking to see if there’s interest in us building and supporting open-source Elm Bazel Rules.

An incomplete list of advantages:

  • Elm can easily fit into a company or invidual’s existing Bazel flow, letting more people try out Elm.
  • Elm output can fit into larger front-end build flows (see the JavaScript and TypeScript build functionalities).
  • Caching can be achieved in both the pulling of dependencies from the Elm package database and in locally building portions of source code – to whatever degree is most helpful.

Is Bazel compatible with Elm’s plans and ideas? Is there a specific shape these Bazel Rules could take to best fit within this community?


We use Bazel and Elm. At the moment we’re getting by by calling NPM scripts that run elm make and the like. So we’d appreciate your work!

Cool, good to hear. Do you have any quirks in your workflow that you’d be concerned about? Do you use elm reactor? Is there any complexity to how you feed in Elm files to elm make, or maybe in how you merge the compiled JavaScript output in with external subscribing-and-commanding-to-Ports JavaScript?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.