2.0.0-beta.4

• Includes all changes from elm-watch 1.2.0.
• When running elm-watch in non-TTY mode, elm-watch’s output becomes a simple log (no cursor movements). Previously, when elm-watch printed the server links in non-TTY mode, the port number was always 0. This has been fixed – the correct port number is now shown.
• CSS files with @import in them can now be hot reloaded in Firefox. The @import:ed CSS files cannot be hot reloaded, though, only the the top-level CSS file containing the @import:s, due to Firefox over eagerly caching style sheets. A warning about this is console.warn:ed on Firefox if a style sheet with @import is detected.

1.2.0

This release fixes a bunch of bugs and edge cases.

The biggest new thing is that elm-watch no longer depends on window.Elm! Previously, elm-watch required window.Elm to exist, for its hot reloading to work. That is no longer the case. This allows for using elm-watch in Node.js (and for postprocessing the output to ESM, if you really want to).

All changes:

• Platform.worker programs can now be run in Node.js with hot reloading, with some setup. Note that you need a recent enough Node.js version that supports the WebSocket global (in short, basically Node.js 22 or later).
• elm-watch no longer requires window.Elm to exist.
• elm-watch now supports postprocessing Elm’s generated JS into ESM (see the end of window.Elm).
• The above changes made it possible for vite-plugin-elm-watch to depend on elm-watch, instead of copying code in a difficult to maintain way.
• The watcher now ignores .stack-work/ folders (for Haskell), similar to how node_modules/ is already ignored, which avoids an error on Linux about watching too many files. For a future version of elm-watch, I’m planning a better way of watching files that shouldn’t need ignoring of certain known folders.
• elm make commands executed by elm-watch now use relative paths instead of absolute paths, because Windows has a maximum command length that some users hit. As a bonus, it looks nicer in error messages (the printed commands are much shorter).
• The page is now reloaded (if needed) due to Cmds in init. Something that can happen is that you open your Elm app in the browser, and then close it. After that, you make changes to some Cmds (probably HTTP requests) that you make in init. Finally, you open the app in the browser again. The previous version (the one you had open in the browser last) is then going to be loaded (no new JS has been compiled yet), so the Cmds from the previous version are going to be run. Then, elm-watch notices the code needs to be recompiled since you made changes. Previously, the new version would then be hot reloaded into the page. Now, the page will be reloaded instead, so that the new Cmds get to run. This should be less confusing.
• elm-watch’s browser UI has always used the maximum z-index so that it stays on top of everything else on the page. However, these days browsers have the so called top layer so that z-index is not enough anymore. If you use popovers or modal <dialog>s on your page, they could end up on top of elm-watch’s UI. elm-watch now renders itself inside a popover to get into the top layer. It also uses a modal <dialog> for the error overlay, which also has an accessibility bonus: <dialog> makes content outside the dialog inert, which means that keyboard users can’t accidentally tab outside the modal, and screen readers won’t read things behind the modal.
• Global text CSS styles can no longer leak into elm-watch’s browser UI.
• Previously, if you didn’t initialize your app at page load, elm-watch’s browser UI would display ❓ and a message suggesting that maybe you did something wrong. Now, elm-watch displays ✅ as usual instead – it’s fine to initialize the app later if you want. If you expand the UI, there’s text with hints in case you actually made a mistake that resulted in no apps being initialized by mistake.
• window.Elm is now updated on hot reload. Previously, only already initialized apps were updated on hot reloads, but window.Elm wasn’t patched with the new code. So if you initialized more Elm apps later, they would be running some old version of your Elm app.
• You can now use quotes or escapes in target names. Previously, that resulted in elm-watch creating JS with syntax errors. Maybe don’t do that anyway, but at least elm-watch isn’t doing something wrong!
• elm-watch used to watch just a single directory recursively – it was called the “watch root”. Now, elm-watch has multiple watch roots. This allows you to put "../../../../" in your source directories without watching a very large part of your drive.
• JSON decode errors are slightly better sometimes, due to upgrading tiny-decoders.
• The ℹ️ emoji no longer appears dimmed in some terminals. In some terminal emulators, dimming text also dims emoji, while in others they emojis are never displayed dimmed. The terminals I’ve used don’t dim emoji, but I’ve seen the emoji being dimmed on others’ computers. elm-watch now only dims the text next to the emoji, not the emoji itself.

Apart from the above, I’ve spent time on upgrading internal tooling of elm-watch, and on making the tests more reliable, which will help me finish the beta version of elm-watch (with the static file server), and making other changes that I want to do.

1.1.3

• Fixed: If elm-watch make fails while installing dependencies and you have postprocess in elm-watch.json, elm-watch now exits instead of hanging.

2.0.0-beta.1

• Built-in HTTPS has been removed.
• You can now execute elm-watch from a Node.js script, and pass in a custom the HTTP server. This allows for setting up HTTPS, or adding proxying.
• The static file server can no longer be tricked into serving files outside the static file directory via percentage escaped double dots.
• CSS hot reloading now works with @import (except in Firefox where it does not seem possible).

1.2.0-beta.3

elm-watch now has built in support for CSS hot reloading!

When .css files in the static files directory that is served changes, elm-watch reloads them in the browser.

I think it makes sense to have in elm-watch, since Elm does not offer a definitive styling answer. CSS can be a pretty nice language, and due to its stateless nature it’s very easy to hot reload. It’s a small, fully reliable and configuration free feature. And it’s gonna make getting started with a little side project much more fun!

1.2.0-beta.2

• Changed: The static file server is no longer enabled by default. Add "serve": "." to elm-watch.json to enable it like it was by default in 1.2.0-beta.1. Or set it to a different directory if you would like to serve some other directory.
• Added: Set the environment variable ELM_WATCH_HOST=127.0.0.1 to restrict the server to only your computer. By default, the server runs on 0.0.0.0 which exposes the server on the local network (so you can test on a phone on the same Wi-Fi for example).

1.2.0-beta.1

This release adds a simple HTTP static file server.

In fact, elm-watch has always had an HTTP server. An HTTP server is needed for a WebSocket connection to be created. This is the reason elm-watch has had an HTTP server at all. WebSockets start with an HTTP request and then “upgrade” to the WebSocket protocol.

Since there’s an HTTP server anyway, it could just as well do something useful apart from handling WebSocket connections. So elm-watch implements a very simple static file server, letting you easily get started with your Elm development.

The idea is to keep this HTTP server simple. For anything more advanced, use your own server instead, just like before.

This makes elm-watch an alternative to elm-live and elm-go in many situations.

Thanks for @joakin for talking to me about this and getting the ball rolling!

1.1.2

Improved: When a new port is added after hot reloading, elm-watch used to log a message to the console using console.info(), saying that you might want to reload the page. What I’ve learned from using elm-watch in real projects though, is that I’d rather want elm-watch to just reload the page for me in that case (like it does in some other cases), to give JavaScript code a chance to set those ports up.

Here’s a use case for reloading:

1. Start elm-watch, but don’t open any tabs in the browser, so no target is connected via WebSocket to elm-watch.
2. Add a new port in Elm. elm-watch just typechecks the code, but does not compile it to JS.
3. Use that port in JavaScript.
4. Go to the app in the browser.

State: The JavaScript is ready for the new port already, but the compiled JS for Elm is old.

What happens: elm-watch starts compiling for real since the target connected via WebSocket, and sends over the new JS. We detect the new port and reload the page. The JavaScript code now gets to set that port up for real.

This is especially helpful if your JavaScript code results in some kind of error when it expects certain ports but those not being available from Elm at page load (since elm-watch compiles lazily until first opened in the browser). I used to be confused why there were errors. Now, the page is automatically reloaded and the errors go away by themselves.

1.1.1

• Fixed: The error overlay in the browser now always displays the errors (for a given target) in the same order as in the terminal. Previously, errors not already present in the overlay would be added at the very end.

• Fixed: Previously, if you had a Platform.worker program (worker programs don’t support the Elm debugger) and for example a Browser.element program (which does support the Elm debugger) in the same output JS file, enabling debug mode resulted in a runtime error. (elm-watch tried running debugger functions for the worker program.) That has now been fixed.

• Fixed: When you switch to optimize mode, hot reloading becomes a bit more tricky. In optimize mode, Elm shortens record fields. For example, view might become G. If you have a lot of record fields, view might become longer, such as a$. I had missed accounting for that the shortened names can contain the dollar sign, so if view (or update or subscriptions, or other interesting “program fields”) happened to get a shortened name with a dollar sign in it, there would be a runtime crash in the browser. This has now been fixed.

• Fixed: Platform.worker programs can be run both in the browser, and in Node.js. Previously, trying to run a worker program in Node.js during development would fail though, due to WebSocket not being defined. (elm-watch injects code that uses WebSocket to do hot reloading.) Now, the injected elm-watch code simply does nothing if WebSocket is not available. (So, no hot reloading!) This is useful if you need to run a Platform.worker program both in the browser and in Node.js. (Note, though, that currently your worker program won’t be fully compiled until it has connected via WebSocket once – because that’s an optimization elm-watch uses in general – which is why this only is useful if you load your worker program both in the browser and in Node.js.)

1.1.0

Note: If you use elm-watch together with run-pty, make sure to update run-pty to 4.0.2 or later!

New features

• Added: An opt-in error overlay in the browser, with clickable error locations. When elm-watch’s browser UI shows “🚨 Compilation error”, click the UI to expand it and then click the “Show errors” button. That opens an overlay which shows the compilation errors. The overlay is visible until you close it again, or until you fix all errors. elm-watch remembers your choice to show errors in the browser per target, and opens the overlay again when there are new errors if you had previously opted to show it. Cool detail: The overlay uses the color theme from your terminal if possible! (That’s why run-pty needs to be updated – to support extracting the colors.)

• Added: Buttons for moving the browser UI to another corner. If you’ve ever felt that the elm-watch browser UI was in the way, you can now move it. The position is remembered per target across page reloads.

• Added: Support for running elm-watch in a Web Worker. Web Workers have no DOM, so you won’t get elm-watch’s browser UI. Instead, elm-watch gives you updates through browser console logs.

• Added: Better support for HTTPS.

• Added: You can now set the ELM_WATCH_EXIT_ON_STDIN_END environment variable (to any value) to have elm-watch end when stdin ends. This is useful to Phoenix users.

Improvements

• Improved: Elm can crash while printing JSON. If you run into such an Elm bug, elm-watch output is now easier to understand: It mentions that “Elm crashed” and shows Elm’s crash message, rather than text about the JSON unexpectedly being cut off.
• Improved: The error message for when window.Elm is undefined.
• Improved: Don’t expand the browser UI when a page reload is needed. That was pretty distracting.
• Changed: The WebSocket URL now uses /elm-watch as path, which helps people running elm-watch behind a proxy and need to do path matching to route to elm-watch and other origins.
• Added: elm-watch now prints a message while it is shutting down, asking you to press ctrl+c (again) to close it more forcefully. Usually you won’t see it, but if you do it helps.
• Fixed: Catch syntax errors when hot reloading.
• Fixed: On the iPhone, if the phone locks while elm-watch is waiting for compilation to finish, the elm-watch browser UI used to be stuck in the “⏳ Waiting for compilation” state. Now, the browser UI should always update when coming back to the page.
• Fixed: Various edge cases around “elm.json related errors”.
• Fixed: If you accidentally run your dev server with HTTP caching, elm-watch no longer gets stuck in a reload loop and instead shows you a helpful error message.
• Fixed: If you rename a target after you have opened it in the browser, elm-watch no longer gets stuck in a weird state. elm-watch used to just complain about target names not matching up, and the only way to fix it was to remove the output JavaScript file. Now the error message tells you to reload the page, and once you do it starts working again with the new target name.
• Fixed: ../ in "source-directories" in elm.json is now supported. Previously, elm-watch would never react to changes to files above elm.json.

(Note: If you installed the 1.1.0 beta versions – there are no changes since 1.1.0-beta.5, and the above is a summary of all changes since 1.0.2.)