`elm make` in watch mode. Fast and reliable.
MIT License
Bot releases are hidden (Show)
elm-watch make
fails while installing dependencies and you have postprocess
in elm-watch.json, elm-watch now exits instead of hanging.Published by lydell 10 months ago
Published by lydell about 1 year ago
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!
Published by lydell over 1 year ago
"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.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).Published by lydell over 1 year ago
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!
Published by lydell almost 2 years ago
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:
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.
Published by lydell almost 2 years ago
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.)
Published by lydell almost 2 years ago
Note: If you use elm-watch together with run-pty, make sure to update run-pty to 4.0.2 or later!
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.
/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.../
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.)
Published by lydell almost 2 years ago
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.Published by lydell about 2 years ago
/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.Published by lydell about 2 years ago
Published by lydell about 2 years ago
../
in "source-directories"
in elm.json is now supported. Previously, elm-watch would never react to changes to files above elm.json.Published by lydell about 2 years ago
Note: If you use elm-watch together with run-pty, make sure to update run-pty to 4.0.2 or later!
Install the latest beta:
npm install elm-watch@beta
Or install this version specifically:
npm install [email protected]
Install latest run-pty (if you use it):
npm install run-pty@latest
Published by lydell about 2 years ago
--help
text to be a little bit more clear.Published by lydell about 2 years ago
elm-watch-node
postprocess script now includes example code that you can copy paste to get started.Published by lydell about 2 years ago
🎉 elm-watch is now out of beta!
Published by lydell about 2 years ago
Published by lydell about 2 years ago
Published by lydell about 2 years ago
elm make
to finish, no matter how long it takes. Due to compiler bugs, certain input can cause elm make
to hang. If you then changed your code to avoid the compiler bugs, elm-watch would notice your change but still wait for that previous elm make
invocation to finish. In this version, elm-watch kills elm make
after 10 seconds if you make a new change while it’s running. The idea is to avoid killing elm make
to avoid corrupting the elm-stuff folder, but after 10 seconds it should have been done long ago.elm make --output=your/output.js
and then read your/output.js
and add the extra hot reloading code and run postprocessing. However, I managed to refresh the page in the browser while that was happening, so I got just Elm’s JS loaded and I was confused why the elm-watch UI wasn’t there. In this version, elm-watch runs elm make --output=elm-stuff/elm-watch/0.js
instead – it first writes to a temporary file, and then writes to your real output path once everything is ready. Note: This also moves elm-stuff/elm-watch-stuff.json
to elm-stuff/elm-watch/stuff.json
, since the temporary files are written in elm-stuff/elm-watch/
and I wanted everything in there. Since elm-watch is a beta and elm-watch-stuff.json contains nothing essential I didn’t bother with any migration or so of it.Published by lydell over 2 years ago