Rails 5: Load lib files in production

141
votes

I've upgraded one of my apps from Rails 4.2.6 to Rails 5.0.0. The Upgrade Guide says, that the Autoload feature is now disabled in production by default.

Now I always get an error on my production server since I load all lib files with autoload in the application.rb file.

module MyApp
    class Application < Rails::Application
        config.autoload_paths += %W( lib/ )
    end
end

For now, I've set the config.enable_dependency_loading to true but I wonder if there is a better solution to this. There must be a reason that Autoloading is disabled in production by default.

11
ruby-on-railsautoloadruby-on-rails-5
crazy thing, and docs still tell you to do auto_load. I was very confused what is going wrong in production env for a new app. And since I started learning with Rails 5 I didn't read migration guide. I filed a doc issue to hopefully get this resolved: github.com/rails/rails/issues/27268 – akostadinov
amazingly, I have two files in lib dir, one file is easily available in Runtime, but another has to be required manually :D – illusionist
@Tobias What solution did you end up with? – geoboy
@geoboy I group code (like Validators) in folders directly in the app/ directory since code there is auto loaded. – Tobias
it's about proper file path and class definition here is what work for me in Rails 5.2: File path: app/services/paylinx/paylinx_service.rb Class definition: module Paylinx class PaylinxService end end. I tried these autoload_paths stuff. doesn't work for me. – NamNamNam

11 Answers

168
votes

My list of changes after moving to Rails 5:

  1. Place lib dir into app because all code inside app is autoloaded in dev and eager loaded in prod and most importantly is autoreloaded in development so you don't have to restart server each time you make changes.
  2. Remove any require statements pointing to your own classes inside lib because they all are autoloaded anyway if their file/dir naming are correct, and if you leave require statements it can break autoreloading. More info here
  3. Set config.eager_load = true in all environments to see code loading problems eagerly in dev.
  4. Use Rails.application.eager_load! before playing with threads to avoid "circular dependency" errors.

  5. If you have any ruby/rails extensions then leave that code inside old lib directory and load them manually from initializer. This will ensure that extensions are loaded before your further logic that can depend on it:

    # config/initializers/extensions.rb
Dir["#{Rails.root}/lib/ruby_ext/*.rb"].each { |file| require file }
Dir["#{Rails.root}/lib/rails_ext/*.rb"].each { |file| require file }
101
votes

I just used config.eager_load_paths instead of config.autoload_paths like mention akostadinov on github comment: https://github.com/rails/rails/issues/13142#issuecomment-275492070

# config/application.rb
...
# config.autoload_paths << Rails.root.join('lib')
config.eager_load_paths << Rails.root.join('lib')

It works on development and production environment.

Thanks Johan for suggestion to replace #{Rails.root}/lib with Rails.root.join('lib')!

35
votes

Autoloading is disabled in the production environment because of thread safety. Thank you to @Зелёный for the link.

I solved this problem by storing the lib files in a lib folder in my app directory as recommended on Github. Every folder in the app folder gets loaded by Rails automatically.

23
votes

There must be a reason that Autoloading is disabled in production by default.

Here is a long discussion about this issue. https://github.com/rails/rails/issues/13142

12
votes

This allows to have lib autoreload, and works in production environment too.

P.S. I have changed my answer, now it adds to both eager- an autoload paths, regardless of environment, to allow work in custom environments too (like stage)

# config/initializers/load_lib.rb
...
config.eager_load_paths << Rails.root.join('lib')
config.autoload_paths << Rails.root.join('lib')
...
9
votes

Just change config.autoload_paths to config.eager_load_paths in config/application.rb file. Because in rails 5 autoloading is disabled for production environment by default. For more details please follow the link.

 #config.autoload_paths << "#{Rails.root}/lib"
  config.eager_load_paths << Rails.root.join('lib')

It works for both environment development and production.

5
votes

In some sense, here is a unified approach in Rails 5 to centralize eager and autoload configuration, in the same time it adds required autoload path whenever eager load is configured otherwise it won't be able to work correctly:

# config/application.rb
...
config.paths.add Rails.root.join('lib').to_s, eager_load: true

# as an example of autoload only config
config.paths.add Rails.root.join('domainpack').to_s, autoload: true
...
2
votes

For anyone struggled with this like me, it's not enough to just place a directory under app/. Yes, you'll get autoloading but not necessary reloading, which requires namespacing conventions to be fulfilled.

Also, using initializer for loading old root-level lib will prevent reloading feature during development.

0
votes

Moving the lib folder to app helped solve a problem, my Twitter api would not run in production. I had "uninitialized constant TwitterApi" and my Twitter API was in my lib folder. I had config.autoload_paths += Dir["#{Rails.root}/app/lib"] in my application.rb but it didn't work before moving the folder.

This did the trick

0
votes

I agree that some dependencies belong in lib and some may belong in app/lib.

I prefer to load all files I've chosen to put in lib for all environments, hence I do this in config/application.rb immediately after requiring the bundle but before opening the MyApplicationName module.

# load all ruby files in lib
Dir[File.expand_path('../../lib/**/*.rb', __FILE__)].each { |file| require file }

This doesn't depend on Rails.root (which isn't defined yet), and doesn't depend on eager loading (which may be off for an environment).

-6
votes

to summarize Lev's answer: mv lib app was enough to have all my lib code autoloaded / auto-reloaded.

(rails 6.0.0beta3 but should work fine on rails 5.x too)