How can I preload concerns in a rails initializer using Rails 6/Zeitwerk?
Asked Answered
A

2

20

I'm working with an initializer that does some monkey patching on app start by including some app concerns into a third party lib. Basically:

# config/initializers/my_initializer.rb

class SomeExternalLib
  include MyConcern1
  include MyConcern2
end

This works fine in Rails 5.2.3, but I got the following deprecation message when upgrading to Rails 6:

DEPRECATION WARNING: Initialization autoloaded the constants MyConcern1, and MyConcern2.

Being able to do this is deprecated. Autoloading during initialization is going to be an error condition in future versions of Rails.

Reloading does not reboot the application, and therefore code executed during initialization does not run again. So, if you reload ApplicationHelper, for example, the expected changes won't be reflected in that stale Module object.

These autoloaded constants have been unloaded.

Please, check the "Autoloading and Reloading Constants" guide for solutions. (called from at /Users/myuser/code/myapp/config/environment.rb:7)

My concerns are in app/controllers/concerns/. After some investigation, I figured out that that path wasn't being autoloaded, but I can't figure out how to make Zeitwerk—Rails 6's new autoloader—load this dynamically. I tried following the pattern for STI autoloading described here, but no luck. Any idea how to address this deprecation warning?

Areaway answered 31/5, 2019 at 21:54 Comment(0)
T
25

As described by @Glyoko's answer, using require on dependencies prevents autoloading in initializers. However, doing so leads to problems during reloading as @Puhlze mentioned in his comment.

I stumbled across an alternate approach that utilizes Rails.configuration.to_prepare in this post.

An example would be:

# config/initializers/my_initializer.rb

Rails.configuration.to_prepare do
  class SomeExternalLib
    include MyConcern1
    include MyConcern2
  end
end

Note that this runs before every request in development but only once before eager loading in production.

Edit: it appears to also work with reloading.

Thirlage answered 29/1, 2020 at 16:37 Comment(2)
Very nice find, stylistically I like this better. Does this preserve code reloading? My impression was that the nature of the problem precluded code reloading in initializers.Areaway
It seems to work with reloading - edited to include this point!Thirlage
A
11

Would help if I read the error message a bit more closely:

Autoloading during initialization is going to be an error condition in future versions of Rails.

Discussion for the change is here and guide is here.

In short, autoloading shouldn't be done in initializers, and this is going to be phased out. Solutions are to either 1) Don't use stuff that needs to be autoloaded in initializers (preferred, obviously), or 2) explicitly require dependencies in initializers.

So I would do:

# config/initializers/my_initializer.rb

require 'my_concern1'
require 'my_concern2'

class SomeExternalLib
  include MyConcern1
  include MyConcern2
end
Areaway answered 3/6, 2019 at 23:56 Comment(1)
The issue with using 'require' is that it will break code reloading in the required files. Unfortunately there doesn't seem to be a better option that will maintain code reloading.Calcification

© 2022 - 2024 — McMap. All rights reserved.