RailsLiveReload currently relies on the ::Rails::Server being available to run, I'm assuming this is just a proxy for understanding that you're in a server process and when Rails users start up their server with rails s this works great.
However my team, and I would think many others may be calling puma or their other web server directly to start their Rails server. rails s has a limited set of options, and it doesn't seem to even respect most of the options in the context of puma (port/bind options). For that reason my team calls bundle exec puma directly and passes it different config files per environment.
All that being said this small PR gives users the option to tell RailsLiveReload through environment variables that it is indeed in a server process, and thus safe to start up.
RailsLiveReload currently relies on the
::Rails::Server
being available to run, I'm assuming this is just a proxy for understanding that you're in a server process and when Rails users start up their server withrails s
this works great.However my team, and I would think many others may be calling
puma
or their other web server directly to start their Rails server.rails s
has a limited set of options, and it doesn't seem to even respect most of the options in the context of puma (port/bind options). For that reason my team callsbundle exec puma
directly and passes it different config files per environment.All that being said this small PR gives users the option to tell
RailsLiveReload
through environment variables that it is indeed in a server process, and thus safe to start up.This may also help solve: https://github.com/railsjazz/rails_live_reload/issues/30