2.0.0-beta.6

elm-watch 2.0.0-beta.5 accidentally didn’t work in Node.js 16 and 18 (only in 19+). This was due to Node.js 19 introducing a crypto global variable, and I accidentally forgot to add import * as crypto from "crypto" in one file and therefore relied on the global.

2.0.0-beta.5

Important

This release contains a security fix. All elm-watch users are encouraged to update.

This release only contains the same changes as in elm-watch 1.2.1.

Note: This release accidentally dropped support for Node.js 16 and 18. Use 2.0.0-beta.6 instead.

1.2.2

elm-watch 1.2.1 accidentally didn’t work in Node.js 16 and 18 (only in 19+). This was due to Node.js 19 introducing a crypto global variable, and I accidentally forgot to add import * as crypto from "crypto" in one file and therefore relied on the global.

1.2.1

Important

This release contains a security fix. All elm-watch users are encouraged to update.

If you don’t have the possibility to update, I recommend unsetting the ELM_WATCH_OPEN_EDITOR environment variable if you have it set. Then the worst security issue (remote code execution) cannot happen.

Note: This release accidentally dropped support for Node.js 16 and 18. Use 1.2.2 instead.

The security fixes were also backported to:

• 1.1.4
• 2.0.0-beta.5

Changes:

• Security: Protect against Cross-Site WebSocket Hijacking

  This disallows web socket connections that don’t know the secret token.

  Previously, a malicious website could connect to your local elm-watch web socket and do the following things:

  • Read compiled Elm JS.
  • Read compilation errors.
  • See your terminal background and foreground colors.
  • Change the compilation mode (debug, standard, optimize).
  • Move elm-watch’s browser UI to another corner.
  • Change whether you prefer the error overlay to be open or closed.
  • Open files in your editor.

  The last point (Open files in your editor) is extra important, since if you misconfigured your shell command for opening your editor, the attacker could run malicious code on your computer – see the next point.

• Security: Validate open in editor command more

  If you have set the ELM_WATCH_OPEN_EDITOR, but forgot to quote the file variable as recommended in the docs, a malicious user could send a web socket message with the file name set to a shell command that then would be evaluated.

  elm-watch now validates that the file is imported by any target, and only runs the command if it is. This prevents sending any shell command as file name.

  This means that if you quote the file variable wrong, you are only “punished” by your command not working for file names with spaces in them, not by getting remote code execution.

• Improvement: Delay Cmds from init instead of reloading the page

  elm-watch 1.2.0 introduced reloading of the page in case Cmds from init need to be re-run. While this removed confusion in one case, it also caused some annoyance by getting an “extra” page reload when opening a tab, seemingly for no reason. Many times, no page reload was actually needed in practice, but it was still performed since elm-watch can’t know if it was needed or not.

  This version of elm-watch reworks that in a smarter way: When you initialize your Elm app, elm-watch now prevents Cmds from init from running immediately (instead, they’ll run ever so slightly later). elm-watch now waits for the web socket to connect first. If we then get a hot reload (because the loaded JS was out of date), run the Cmds from the new, hot reloaded, init instead. Otherwise proceed with the original (delayed) Cmds from the original init.

1.1.4

Important

This release contains a security fix. All elm-watch users are encouraged to update.

This backports the security fixes from elm-watch 1.2.1.

Some people reported having trouble updating from 1.1.3 to 1.2.0, so I figured I’d backport the security fixes on top of 1.1.3 (as this release, 1.1.4) for their sake.

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!