Serve: Any option for live-reloading?

Created on 1 Oct 2017  路  7Comments  路  Source: vercel/serve

Any option for live-reloading?

Something like this? https://github.com/tapio/live-server

Most helpful comment

There are several options out there, but none suited my purpose, so I made one.

https://github.com/shannonmoeller/livery

{
  "scripts": {
    "start": "serve"
    "watch": "lr | serve"
  }
}
{
  "scripts": {
    "dev": "run-p watch-*",
    "dev-serve": "serve web",
    "dev-watch": "lr 'web/assets/**/*.{css,js}'"
  }
}

All 7 comments

@leo what do you think about this feature request? I'm not sure having it in serve. Do you consider extending serve in this way? If so, I'd like to create a pull request for this.

I think this is too much for core. People can wrap serve if they want it... 馃槉

hi guys, I came here looking for live-reloading functionality. What CLI apps would you suggest as the best alternative that can do serve + livereload? I'm looking for turnkey CLI app, equivalent to serve but with live reloading because I hate clicking "refresh" button when it can be automated.
cheers

@revelt a bit late to the party but there's browser-sync

i think reloading is important too. maybe a cli version of live reload

There are several options out there, but none suited my purpose, so I made one.

https://github.com/shannonmoeller/livery

{
  "scripts": {
    "start": "serve"
    "watch": "lr | serve"
  }
}
{
  "scripts": {
    "dev": "run-p watch-*",
    "dev-serve": "serve web",
    "dev-watch": "lr 'web/assets/**/*.{css,js}'"
  }
}

I wanted to understand how live reloading actually worked once. So I tried rolling my own in a determined _zero dependency_ fashion with the aim of learning as mush as possible. I hit a wall pretty quick at the web socket connection, implementing this myself was not something I wanted to do so I searched for an alternative method for the dev server to communicate with the browser.

I stumbled across connection-type: text/event-stream which creates a one way stream of data that the browser that can subscribe to using the EventStream API. Both these features are native to their respective platforms (node and the browser) so it barely adds anything to either codebase.

Now all that remains to be done by the server when --watch option is present is to:

  • Inject the subscriber code into the html document that is being served
file += `
  <script>
    const source = new EventSource('http://localhost:5000');
    source.onmessage = e => location.reload(true);
  </script>
`
  • Watch the file system and send a message to the browser on any change
fs.watch(path.join(cwd, root), { recursive: true }, () =>
  sendMessage(res, "message", "reloading page")
);

I ended up adding this feature to my own little dev server and it has been working well so far. Recently I came back to use zeit/serve for a project thinking that it had live reload but found it doesn't!

Would you be interested in me making a PR that includes the above implementation to see how it might look? I agree with @leo that a full blown web socket implementation would be too much for core.. but this approach offers quite a bit of bang for its buck.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Mugen87 picture Mugen87  路  3Comments

malinda1986 picture malinda1986  路  6Comments

nermin99 picture nermin99  路  3Comments

leo picture leo  路  5Comments

fabricionaweb picture fabricionaweb  路  3Comments