Community BETA for Elm 0.19.1

On a 28k LOC (sorry, less than 50k)


128 modules 3.385 secs
  1 module  0.740 secs


128 modules 1.941 secs
  1 module  0.314 secs

       Full compile: 43% decrease!
Incremental compile: 58% decrease!

I can confirm on Windows 10 that the Map! bug when using --debug flag is resolved the project I work on.

Thank you so much for this beta. So happy to have the debugger back. :bowing_man:


Holly effin durians! I just migrated from 0.18.0 on a 51K app where changing this one critical module caused ~3min compile time. And now with 0.19.0:

Success! Compiled 197 modules.                                       

real    0m5.324s
user    0m4.845s
sys     0m0.436s

But then there is 0.19.1:

Success! Compiled 1 module.

real    0m0.158s
user    0m0.060s
sys     0m0.082s

Are. You. Kidding. Me.
What have you done, Evan!


I’m pretty sure I won’t have time to test this particular beta, but in the future, it’d be easier for those of us on source-based distros (like NixOS) to test betas if you publish a tag in the git repo. Thanks!

1 Like

Aren’t you comparing the compilation of 197 modules vs. 1 module? Most likely increment compilation? Or am I misunderstanding something?

Incremental is the only type that matters to me. I believe I made sure I edited just that one key module before running the compiler. That accurately describes my worst case scenario.

1 Like

To test it with create-elm-app:

  1. Inject new elm runtime
❯ mv elm elm_019
❯ cp ~/Downloads/elm-0.19.1-beta-1-mac elm

❯ sudo chmod +x elm
  1. Adjust hot loader
    ❯ vi elm-hot/src/inject.js # on line 35
    if (false) {
        throw new Error("Compiled JS from the Elm compiler is not valid. You must use the Elm 0.19 compiler.");
  1. Change the elm version in the elm-app created project folder to 0.19.1
1 Like

Those are both for incremental compilation times. One of the big improvements in 0.19.1 is that it checks if the public API of a module has changed. If it has not changed, there is no need to recompile any of the modules that import it.

So @Birowsky is seeing it go from 197 modules to 1 module as a result of this change. There are still 196 modules that depend on the API of this one critical module, but the compiler can skip them for most edits!

Note 1: You will be able to increase the benefits of this optimization by using an explicit exposing in your modules. That way you can add new helper functions internally without changing the public API, thereby getting the faster compiles in more cases.

Note 2: This optimization also means that the worst case is improved. When an public API is changed, you must check modules that import it directly. Maybe they are broken. But you do not need to check on any modules that import it indirectly. So if your project was like:

    /     \
   A       B
  / \     / \
 C   D   E   F 
/ \ / \ / \ / \

When you change the public API of BigModule you only need to check on A and B. Their API stays the same, so you can skip compiling C, D, E, F, and everything else. So even in the worst case, it is unlikely that @Birowsky could trigger a 197 module recompile when using the new compiler.



The BETA is not producing many reports of unexpected or buggy behavior. That’s encouraging!

It looks like the next steps are:

  1. Finish up the blog post announcing the release. I am working on that, and it is actually helping improve the error messages quite a bit. (E.g. making color usage more consistent, making errors more helpful, etc.)
  2. Get elm-test working with the new binary format of various build artifacts. There is work going on by various authors and maintainers to get that working.

Once those are both in order, it looks like it’ll make sense to do a BETA-2 or RC-1 just to be safe. There are a couple fixes and changes, so it’d be good to get some eyes on them!

Thanks to everyone who has tried out the BETA so far! Really excited about how it is coming together to make a more solid foundation! :smile:


That’s great to hear. If you’d make a tag in github, I can prepare a Nix package for everyone to be able to easily test RC-1 easily on macos/linux.


It would be nice to have ARM binaries as well.

Wait what? How would you use ARM build? You’ve set up some CI on Raspberry Pi? Are you in the beginning of this process or is it something you rely on?

I would use it on an Android Tablet to do Elm development. I tried to compile it myself, but the tablet had only 2GB of memory so that failed. Probably should have launched a bigger ARM instance in the AWS cloud to compile it, but having a ready made binary would help.

1 Like

Here’s a guide on doing it yourself. I suppose you can take the 0.19 source and take some advice from this guide? Let me know if it works out! :sunny:

@berend The Nix packages provide (prebuilt) ARM versions of Elm (I successfully use them for developing on my Android tablet). I would imagine that if the RC makes it into Nix then they will also eventually provide prebuilt packages of that there too (or if not for the RC, certainly for 0.19.1)…

1 Like

Sorry for the delay, I’ve been away. I’ve posted the issue at as requested. Thanks again!

Just changed elm to this 0.19.1 beta for my private project and I see this:

Dependencies ready!
-- INCOMPATIBLE DEPENDENCIES ------------------------------------------ elm.json

The dependencies in your elm.json are not compatible.

Did you change them by hand? Try to change it back! It is much more reliable to
add dependencies with elm install or the dependency management tool in
elm reactor.

Please ask for help on the community forums if you try those paths and are still
having problems!


  1. I don’t like that I don’t know the specifics of incompability.
  2. “Dependencies ready” vs the fact that elm-stuff\0.19.1-beta-1 folder contains only the lock file (meaning, it’s almost empty).

My elm.json is:

    "type": "application",
    "source-directories": [
    "elm-version": "0.19.1",
    "dependencies": {
        "direct": {
            "GlobalWebIndex/cmd-extra": "1.1.1",
            "NoRedInk/elm-json-decode-pipeline": "1.0.0",
            "dillonkearns/elm-graphql": "4.2.1",
            "elm/browser": "1.0.1",
            "elm/core": "1.0.2",
            "elm/file": "1.0.5",
            "elm/html": "1.0.0",
            "elm/http": "2.0.0",
            "elm/json": "1.1.3",
            "elm/regex": "1.0.0",
            "elm/time": "1.0.0",
            "elm/url": "1.0.0",
            "elm-community/array-extra": "2.1.0",
            "elm-community/list-extra": "8.2.0",
            "elm-community/maybe-extra": "5.0.0",
            "justinmimbs/date": "3.1.2",
            "jweir/elm-iso8601": "6.0.0",
            "krisajenkins/remotedata": "6.0.1",
            "mdgriffith/elm-ui": "1.1.0",
            "myrho/elm-round": "1.0.4",
            "periodic/elm-csv": "2.0.0",
            "truqu/elm-md5": "1.1.0"
        "indirect": {
            "Skinney/murmur3": "2.0.8",
            "elm/bytes": "1.0.8",
            "elm/parser": "1.1.0",
            "elm/virtual-dom": "1.0.2",
            "lukewestby/elm-string-interpolate": "1.0.3",
            "zwilias/elm-utf-tools": "2.0.1"
    "test-dependencies": {
        "direct": {
            "elm-explorations/test": "1.1.0"
        "indirect": {
            "elm/random": "1.0.0"

Here’s a data point from our team (I shared our comparison between Elm 0.18 and 0.19 on Twitter a while back):

Our project is now a little bit larger (28k LoC). Here’s what I see in terms of compilation times between 0.19 and 0.19.1-beta:

Compiler Time
elm-0.19 2.196 seconds
elm-0.19.1-beta 1.165 seconds

Incremental recompilation is almost instantaneous (usually under 0.2 seconds).

Thanks for taking the time to make these types of improvements, @evancz (and the rest of the Elm core team)!


I think you’re having this problem which looks like it pertains to 0.19

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