Caddy: Livereload

[sinky]

Example: http://corte.si/posts/devd/intro/index.html

Would be awesome to have this in caddy.
Autoinject a script to html. Caddy watches the root for changes an tells the script to reload the page.
The script could watch a special url that returns an hash or number and if caddy changes this hash/number the script reloads the page on the next check.
Or a websocket.

[mholt]

Would love to see this as an add-on (plugin). I think it'll be really helpful in development. WebSockets would shine here.

[JHKennedy4]

I'm writing a hot module reloader right now based on capaj/jspm-hot-reloader and a simple filesystem watcher using os/fsnotify, but I'm getting 10+ second websocket responses with just cat and nothing back from my watcher script.

Would love to get this working, but if the WS responses are this slow it probably won't be worth much in practice.

My Caddyfile:

localhost:8080
websocket /hot-watcher caddy-hot-reloader
log / stdout "{method} {uri} {latency}"

My socket client:

    this.socket = new window.WebSocket('ws://' + backendUrl)

    this.socket.onmessage = (e) => {
      console.log(e)

      let moduleName = e.data // looking for the file changed

      if (moduleName === 'index.html') {
        document.location.reload(true)
      } else {
        this.hotReload(moduleName)
      }
    }

    this.socket.onopen = (e) => {
      console.log('hot reload connected to watcher on', backendUrl)
    }

    this.socket.onclose = () => {
      console.log('hot reload disconnected from', backendUrl)
    }

[mholt]

@JHKennedy4 That's cool. What is caddy-hot-reloader? Are you sure it works by itself (without websockets)? Also, if you have a chance, pull the latest from master as a data race was recently fixed in the websocket middleware.

[JHKennedy4]

Caddy-hot-reloader (which I've literally just decided to rename to caddy-hot-watcher) is almost exactly the fsnotify example code. It's a very rough work in progress, and at the moment it just returns the path of any file that's modified in my static asset directory (./app).

I'm confident that the watcher code works correctly, and I've actually seen it send a message across one time, but I'm still bogged down with getting consistent ws responses. I'll pull down from master and see if that solves my problem.

[JHKennedy4]

master did the trick :100:

[mholt]

@acmacalister ^^ check that out. Great work, thanks for the fix! :+1:

@JHKennedy4 How interested would you be in turning that into a Caddy add-on?

[JHKennedy4]

Definitely interested. Any requirements I should read up on?

[mholt]

Nothing special, but here's a guide to extending Caddy that you will find helpful. It has examples and basic function stubs you can use as templates to get started. Feel free to join us on Slack or ask here if you have questions!

[JHKennedy4]

@sinky 90% of what you need is in caddy-hot-watcher though it's very much an alpha I hacked together today. It just recursively adds files to fsnotify's watcher from the root it's run in and writes the filename of written files to stdout. Just need to write the script that listens to it.

Take a look at caddy-hot-loader for the socket stuff. Again, this was all hacked together today, so likely rough around the edges. I've only tested in Chrome so far and have made no accommodations for older browsers.

I've got everything set up for hot module reloading with jspm/System.js, but I think a basic livereload might have broader utility and would make a very nice Caddy extension given that it wouldn't have any other external dependencies. I'm happy to tackle it as I continue work on the hot module stuff, but feel free to charge ahead.

[sinky]

Looks quite nice. Looking forward to a caddy addon.

[JHKennedy4]

ok, so I'm digging into this and I'd like to get an idea of what people would actually want out of a livereload plugin. Obviously I'd like to minimize dependencies and make it as widely applicable as possible, but I'd like to balance that against functionality.

As is, my two services can perform a livereload if index.html is changed, and a hot reload if any js or css is changed (or it should, I still need to work out some kinks). The broadest version of this I can envision is a comprehensive hot/live reloader that watches any files on the file system, and depending on their type initiates the appropriate reload. It would likely need to leverage the System.js polyfill for browser based script loading (which is ideal when using HTTP/2 anyways).

A more limited version of the plugin could just do livereload, and simply watch for any file change. It would definitely be easier to build, but be less awesome IMHO. It will definitely take a bit more work to get the comprehensive approach working (especially with various module systems), but I think it would be worth it.

The biggest downside of the comprehensive approach is that you would need to provide an alternative script loading story for production. My preference is to avoid tying anyone to any particular library of strategy, while being feature complete out of the box.

Does anyone have a preference?

[mholt]

I'd suggest starting simple, and going from there depending on demand, the tradeoff for complexity, etc. I can understand the value of reloading the HTML page if one of its JS or CSS (or image?) dependencies changes, but that does sound a bit involved, especially for a first stable iteration.

Keep in mind, too, that the server-side stuff will need to have at least some tests.

[JHKennedy4]

Yup, that's pretty much my line of thinking. Should be fun :)
On Fri, Nov 13, 2015 at 6:49 AM Matt Holt [email protected] wrote:

I'd suggest starting simple, and going from there depending on demand, the
tradeoff for complexity, etc. I can understand the value of reloading the
HTML page if one of its JS or CSS (or image?) dependencies changes, but
that does sound a bit involved, especially for a first stable iteration.

Keep in mind, too, that the server-side stuff will need to have at least
some tests.

—
Reply to this email directly or view it on GitHub
https://github.com/mholt/caddy/issues/325#issuecomment-156451975.

[mholt]

@JHKennedy4 How's this going? I still get requests for this, I think your add-on would be used by quite a few people. :)

[JHKennedy4]

Holidays pushed my side projects out a bit. Still high on my todo list.
On Mon, Jan 11, 2016 at 9:25 AM Matt Holt [email protected] wrote:

@JHKennedy4 https://github.com/JHKennedy4 How's this going? I still get
requests for this, I think your add-on would be used by quite a few people.
:)

—
Reply to this email directly or view it on GitHub
https://github.com/mholt/caddy/issues/325#issuecomment-170625356.

[bep]

See https://github.com/spf13/hugo/blob/master/livereload/livereload.go

Doing explicit reolad of a given CSS or image works beautiful ... the browser just magically refreshes with no "hard reload".

[mholt]

@sinky, @JHKennedy4, and @bep - thanks for your comments! There is a lot of good stuff here, so I have linked to this issue from a thread in our community forum where we are aggregating ideas/requests for Caddy plugins.

Hope you know there is still interest in this! :+1: Is this an issue we need to keep open?

[adrinux]

Front end orientated as I am I'd have to say what I'd want is Browsersync: https://www.browsersync.io/ type functionality.

Isn't this just reinventing the browsersync/livereload wheel in golang? Is build tooling something that should be implemented by Caddy, even as a plugin? Having said that it might be nice not to deal with the whole node.js website build stack =D

[mholt]

BrowserSync does a lot more. All this plugin would do is reload the page if one of the resources on the page changes.

Going to close this along with all the other 'addon' issues, since there isn't anything for us to act on here, but I do hope somebody will implement this plugin before too long!