Take the 2-minute tour ×

I'm creating a new engine for a rails 3 application. As you can guess, this engine is in the lib directory of my application.

However, i have some problems developing it. Indeed, I need to restart my server each time I change something in the engine.

Is there a way to avoid this ?

Can I force rails to completely reload the lib directory or a specific file and his requirements for each request ?

Thanks for your help :)

share|improve this question
add comment

11 Answers

up vote 15 down vote accepted


  • put this in config/application.rb

    config.eager_load_paths += ["#{Rails.root}/lib"]

  • remove require statements for your lib files


Let me explain in detail.

I don't know why this answer is accepted, since it doesn't help with reloading lib folder on each request. First I thought that it works for Rails 2, but the question clearly states that it was for Rails 3 and the release date of 3.0.0 is before the date of the answer.

Other answers seem over-complicated or don't provide a real solution.

I decided to investigate things a little, because it was bothering me and I've even found out that people have a workaround for this and it involves saving lib files inside app/models in development and then moving it to /lib when done. We can do better, right?

My solution is tested against:

  • Rails 3.0.20
  • Rails 3.1.12
  • Rails 3.2.13
  • Rails 4.0.0.rc1

Put this into your config/application.rb:

# in config/application.rb
config.eager_load_paths += ["#{Rails.root}/lib}"]

That's it!™

Make sure you put it here since it will not work if you put it in config/environments/development.rb, for example.

Make sure your remove all the require statements for your /lib code since require statements will also cause this solution to not work.

This code implicitly requires your code, so if you do environment checks (which are unnecessary) and instead of the above code, you decide to write something like this:

# in config/application.rb
config.eager_load_paths += ["#{Rails.root}/lib"] if Rails.env.development?

you should watch out on the old require statements, since they are still required on all the non-development environments, in this scenario.

So if you still decide to do environment checks, make sure you do inverse checks for require statements. Otherwise you'll get bitten!

require "beer_creator" unless Rails.env.development?

You might think that writing entire paragraph about something that's unnecessary is also unnecessary, but I think that warning people about something that's necessary when doing something unnecessary is also necessary.

If you would like to know more about this topic, check out this little tutorial.

share|improve this answer
That was a while back buck you can also use load without the eager_load_path. Create helper that take the string as a parameter and use load if env is dev and require if env is prod. If you try that please let me know if it works :) –  Nicolas Guillaume May 21 '13 at 19:06
Doesn't seem to work on Rails 3.0.20 with or without the extra '}' at the end of the string. –  Ritchie Nov 6 '13 at 1:51
This didn't work for me on 3.2.13 -- instead, after adding the eager_load_paths, all my other files (controllers + models) stopped getting reloaded between requests also! (Goes back to normal if I remove that line.) Bizarre. I finally got it working with this answer: stackoverflow.com/a/10954365/1164573 –  Sherwin Yu Dec 6 '13 at 8:07
Are you able to get this to work in Rails 4.1? I have a question (with bounty) about this here, but have not found an answer yet. –  Zabba Dec 10 '13 at 18:59
add comment

I couldn't get any of the above to work for me so I dug in the Rails code a bit and came up with this:

New file: config/initializers/reload_lib.rb

if Rails.env == "development"
  lib_reloader = ActiveSupport::FileUpdateChecker.new(Dir["lib/**/*"]) do
    Rails.application.reload_routes! # or do something better here

  ActionDispatch::Callbacks.to_prepare do

Yes, I know it's disgusting but it's a hack. There might be a better way to trigger a full reload, but this works for me. My specific use case was a Rack app mounted to a Rails route so I needed it to reload as I worked on it in development.

Basically what it does is it checks if any files in /lib have changed (modified timestamp) since last loaded and then triggers a reload if they change.

I might also mention I have this in my config/application.rb


Which just by default makes sure everything in my lib directory gets loaded.


share|improve this answer
Excellent - works great if you are subclassing from a gem. I used this with Grape (eg /lib/appname/api.rb starts with Appname::API < Grape::API) and it works (while the autoload_paths fix doesn't). –  nfm Mar 11 '11 at 1:37
@pbhogan The method signature for FileUpdateChecker#initialize has changed a bit in Rails 3.2.x. Get rid of true and everything should work fine again. –  Aaron Brethorst Jul 25 '12 at 22:48
This worked for me with the Grape gem also, thanks @nfm. I did however have to change the FileUpdateChecker syntax slightly to: ActiveSupport::FileUpdateChecker.new([], Dir["lib/**/*"]) –  Brian Armstrong Jul 29 '12 at 2:44
Can someone edit this post and explain how to reload files from the lib directory? The current example only reloads routes (if I'm reading it correctly), which doesn't answer the question. –  Tyler Collier Aug 6 '12 at 3:32
@Tyler Collier Have you tried it? It reloads all files in lib/**/*. –  Thilo Aug 15 '12 at 8:34
show 1 more comment

You have to add


to your Application class in config/application.rb


share|improve this answer
It's probably best to put it in development.rb –  nilbus Feb 7 '12 at 15:37
This allows my files in lib to be autoloaded (loaded when you access the constant by the same name), but doesn't seem to help cause them to be reloaded on each request/when modified. I'm on Rails 3.2.3. –  Tyler Rick May 3 '12 at 1:16
yes, with this code files in lib are autoloaded but not reloaded, BUT when you put your files somewhere else they reloads: $:.unshift(config.root); config.autoload_paths += %w(app/models/misc) I think about my lib files as business logic, and I put business logic into my models also, so they are my Models but not db-persisted, and it is right that they are in app/models/misc and not in lib. –  Lev Lukomsky Aug 28 '12 at 9:49
add comment

Since we are talking Rails, the easiest way is to 'require' your lib/* .rb files using 'require_dependency'. So long as the controller/helper/etc (.rb files under app/) uses require_dependency instead of just require reloading works, without the need to do anything funky.

Before I went down that track, the only solution that worked was the one on hemju.com, but I really did not want to have to hack the ApplicationController for Dev speed.

share|improve this answer
This worked for me, nicely –  Peter Ehrlich Dec 14 '11 at 0:26
This seems to have worked for me too. Too bad it can't just work with a plain require though... –  Tyler Rick May 3 '12 at 2:15
Works great with Rails 3.2.6. This is the best and cleanest answer definitely. –  Georges Nov 29 '12 at 18:31
add comment

In RAILS 3, here's the secret sauce to auto-reload lib files. The code below's a bit overkill, for the example, but it's what I did to make it work. You can change the message in YoYo#gogo and see it on the screen each page load. Remove out the initializer and it stays the same.

/config/initializers/lib_reload.rb (new file)

ActiveSupport::Dependencies.explicitly_unloadable_constants << 'YoYo'


class YoYo
  def gogo


require 'yo_yo'
class HomeController < ApplicationController
  def index
    @message = YoYo.new.gogo
share|improve this answer
I believe that in Rails 3 it is autoload_once_paths instead of load_once_paths –  Daniel X Moore Feb 7 '11 at 6:52
best answer, but you can shorten File.expand_path(File.dirname(FILE))+'/lib' with "#{Rails.root}/lib" and also put an if Rails.env.development? check –  makevoid Jun 25 '12 at 15:22
add comment

Here is my version inspired from @pbhogan's answer that reloads all the ruby files in your rails /lib directory when any of those files is changed.

It also silences warnings to avoid messages regarding already initialized constants.

Works as of Rails 3.2.8

if Rails.env.development?

  lib_ruby_files = Dir.glob(File.join("lib/**", "*.rb"))
  lib_reloader ||= ActiveSupport::FileUpdateChecker.new(lib_ruby_files) do
    lib_ruby_files.each do |lib_file|
      silence_warnings { require_dependency(lib_file) }

  ActionDispatch::Callbacks.to_prepare do

share|improve this answer
add comment

Updated answer

I sum up all my findings on my blog, you better look there:

Old answer

I looked around for a solution for this too, and (for completeness' sake and also to point others into this direction) here is what I found.

As of Rails3.1, engines can easily be generated through the command rails plugin new my_plugin --full. This generates the skeleton for an engine.

--full means that the engine will be "merged" right into the including application, so that for example controllers should be directly accessible as if they were defined in the including app. This lets you e.g. have a helper file in my_engine/app/helpers/my_helper.rb that will be merged right into your including app's app/helpers/my_helper.rb helper.

There's another option --mountable which creates a namespace for the engine so that its controllers etc. will never collide with the including application's ones. This results in e.g. a helper being in my_engine/app/helpers/my_engine/my_helper.rb which won't collide with a helper app/helpers/my_helper.rb in your including app.

Now the more interesting part:

Within the generated engine's test folder, there's a dummy folder which holds a complete Rails application! What's it for?

When you develop an engine, its functionalities are meant to work completely on their own, and it should also be tested completely on its own. So it's the "wrong" way to develop an engine "within" another Rails app (though this intuitively often will feel right when extracting existing functionalities from a Rails app into an engine), and so theoretically it is also not needed to reload an engine's code with every request to the including application.

The "right" way seems to be this: develop and test your engine, as if it were a full Rails app using the dummy app! Therein you can do everything you can do in any "normal" Rails app, e.g. create controllers, models, views, etc. which use the functionalities the engine should provide. You also can normally start a server using rails s in your test/dummy directory and access the dummy app on localhost:3000, and when running your tests, the dummy app is automatically used for integration tests. Quite nice! :-)

You have to be careful where to put your stuff:

  • Any functionality that is meant to be used within another Rails app goes into my_engine/app, while any functionality that is only needed to test the engine's functionality goes into test/dummy/app.

Then afterwards you can easily load your engine in your main app's Gemfile like this: gem 'my_engine', :path => 'path/to/my_engine' or publish it to GitHub as a gem.

(One interesting thing (and to come back to this topic's subject) is that when I start the dummy's server, then all changes in the engine seem to be reflected within it! So somehow it seems to be possible to include an engine within a Rails app without caching it...? I don't know how this happens.)

So to sum up: an engine provides functionality that can stand completely on its own, so it should also be developed and tested on its own. Then, when it has reached a stable state, it can be included by any other app that needs its functionality.

Here's some resources I find useful:

I hope you find this answer useful. I'm still very new to engines in general, so if there's any wrong information, please tell me, and I'll correct it.

share|improve this answer
add comment

note that in Rails 3 "load_once_paths" becomes "autoload_once_paths."

Also, it appears that it should be empty unless you explicitly put something in it.

share|improve this answer
add comment

Also, make sure that you comment out the following line in application.rb (in addition to @dishod's solution), and make sure that your module name is the same as your file name (otherwise, rails won't be able to find it)

#Dir.glob("./lib/*.{rb}").each { |file| require file } # require each file from lib directory
share|improve this answer
add comment

Worked for Rails 3.2.13 for reloading lib inside of gem of an app:

require_dependency 'the_class'


config.autoload_paths += %W(#{config.root}/../fantasy/lib)

share|improve this answer
add comment

Add to application_controller.rb or your base controller:

  before_filter :dev_reload if Rails.env.eql? 'development'

  def dev_reload
    # add lib files here
    ["rest_client.rb"].each do |lib_file|
      ActiveSupport::Dependencies.load_file lib_file

Worked for me.

share|improve this answer
add comment

Your Answer


