Revisit Dev Tools live reload capabilities

[vpavic]

Currently, as explained in LiveReload section of the reference manual, Dev Tools support for live reload requires use of 3rd party browser extensions. The suggested extensions have been unmaintained for more than a few years now as evident by the last publishing dates and the activity in the appropriate repos:

• https://addons.mozilla.org/en-US/firefox/addon/livereload-web-extension/
• https://chrome.google.com/webstore/detail/livereload/jnihajbhpnppcggbcgedagnkighmdlei
• https://github.com/livereload/livereload-extensions
• https://github.com/twolfson/livereload-extensions

In addition to that, the linked livereload.com site itself is down, which apparently isn't a transient issue as wayback machine was last able to index it on Jun 10th.

With this in mind Spring Boot should IMO revisit live reload capabilities of Dev Tools module. Additionally, some other technologies that I've work with recently offer live reload capabilities without requiring browser extensions at all. Some examples of that are hugo and even IntelliJ IDEA. Both of these work by appending the script within the served HTML, which contains some code that updates the page when needed. Something like this would both improve the developer experience and also remove the requirement to use (unmaintained) 3rd party browser plugins.

[philwebb]

Thanks for the suggestion, I think we should revisit this at some point. There's also https://browsersync.io/docs/gulp which might help.

[vpavic]

While the livereload browser extensions aren't maintained, the core livereload/livereload-js project is. I've tried pulling it in as a WebJar and including it in my templates and it just works. I can try putting together a PR that explores this approach, if you don't have anything against it.

[philwebb]

That would be useful if you have time, but we're not likely to get to this until after 3.0 has been released so no rush on our side. Perhaps we might be able to bundle livereload-js ourselves so we don't need to use webjars.

[vpavic]

That would be useful if you have time, but we're not likely to get to this until after 3.0 has been released so no rush on our side.

Got it.

Perhaps we might be able to bundle livereload-js ourselves so we don't need to use webjars.

I too was thinking the solution that lands in Spring Boot should include the script in spring-boot-devtools (perhaps by shading it?) rather than pulling it in as a transitive dependency.

In the meanwhile, I did a PoC for this that's serving me well in a couple of projects. I've extracted it to vpavic/poc-spring-boot-livereload in case anyone else finds this interesting.

Feel free to assign this issue to me, I'll try to prepare a PR over the next couple of weeks.

[wilkinsona]

Thanks, @vpavic. I've assigned the issue to you.

[skiyooka]

In revisiting this, it would be very nice to have live reloading when Spring Boot is behind a reverse proxy e.g. nginx.

With Next.js they are using WebSockets to handle the reloading communication. No browser extension is required.

For example the following nginx reverse proxy directive allows live reloading:

        location / {
            proxy_pass http://localhost:3000/;  # note trailing slash!
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }

Is it feasible for Spring Boot live reloading to use WebSockets and ditch the browser extension all together?

[tschuehly]

Would it be possible to trigger a LiveReload after "Update classes and resources"? This is the default behaviour on frame deactivation in IntelliJ now, after @joshlong opened a Issue for that: YouTrack

Something like this:

class compilation -> hot swap -> live reload event

If I call applicationEventPublisher.publishEvent(ClassPathChangedEvent(this, changeSet, true)) in my FileChangeListener the hot reload websocket message is sent before IntelliJ hot swapped it.

[vpavic]

Long overdue, but I've finally submitted a PR that attempts to resolve this - see #43697.