Skip to content

Latest commit

 

History

History
104 lines (75 loc) · 3.96 KB

README.md

File metadata and controls

104 lines (75 loc) · 3.96 KB
Raw

Rack::LiveReload Build Status Maintainability

Hey, you've got LiveReload in my Rack! No need for browser extensions anymore! Just plug it in your middleware stack and go! Even supports browsers without WebSockets!

Use this with guard-livereload for maximum fun!

Installation

Rails

Add the gem to your Gemfile.

gem "rack-livereload", group: :development

Then add the middleware to your Rails middleware stack by editing your config/environments/development.rb.

# config/environments/development.rb

MyApp::Application.configure do
  # Add Rack::LiveReload to the bottom of the middleware stack with the default options:
  config.middleware.insert_after ActionDispatch::Static, Rack::LiveReload

  # or, if you're using better_errors:
  config.middleware.insert_before Rack::Lock, Rack::LiveReload
  
  # or, if you're using better_errors with rails 6.
  config.middleware.insert_before Rack::Runtime, Rack::LiveReload

  # ...
end

Tweaking the options

# Specifying Rack::LiveReload options.
config.middleware.use(Rack::LiveReload,
  min_delay        : 500,    # default 1000
  max_delay        : 10_000, # default 60_000
  live_reload_port : 56789,  # default 35729
  live_reload_scheme : 'ws', # default ws, use wss for ssl
  host             : 'myhost.cool.wow',
  ignore           : [ %r{dont/modify\.html$} ]
)

In addition, Rack::LiveReload's position within middleware stack can be specified by inserting it relative to an existing middleware via insert_before or insert_after. See the Rails on Rack: Adding a Middleware section for more detail.

Sinatra / config.ru

require 'rack-livereload'

use Rack::LiveReload
# ...or...
use Rack::LiveReload, min_delay: 500, ...

How it works

The necessary script tag to bring in a copy of livereload.js is injected right after the opening head tag in any text/html pages that come through. The script tag is built in such a way that the HTTP_HOST is used as the LiveReload host, so you can connect from external machines (say, to mycomputer:3000 instead of localhost:3000) and as long as the LiveReload port is accessible from the external machine, you'll connect and be LiveReloading away!

Which LiveReload script does it use?

  • If you've got a LiveReload watcher running on the same machine as the app that responds to http://localhost:35729/livereload.js, that gets used, with the hostname being changed when injected into the HTML page.
  • If you don't, the copy vendored with rack-livereload is used.
  • You can force the use of either one (and save on the cost of checking to see if that file is available) with the middleware option :source => :vendored or :source => :livereload.

How about non-WebSocket-enabled browsers?

For browsers that don't support WebSockets, but do support Flash, web-socket-js is loaded. By default, this is done transparently, so you'll get a copy of swfobject.js and web_socket.js loaded even if your browser doesn't need it. The SWF WebSocket implementor won't be loaded unless your browser has no native WebSockets support or if you force it in the middleware stack:

use Rack::LiveReload, force_swf: true

If you don't want any of the web-sockets-js code included at all, use the no_swf option:

use Rack::LiveReload, no_swf: true

Once more browsers support WebSockets than don't, this option will be reversed and you'll have to explicitly include the Flash shim.