reactjs
Initializers and react-rails gem placement in Gemfile suspect load order issue with `after: :load_config_initializers` option
I'm sorry to post an issue that is missing crucial evidence, but some debugging of a recent config loading bug makes me suspect that the react-rails railtie.rb may be modifying the load order of initializers, and preventing the values in Rails.application.config being as expected.
Whether this happens or not appears to be partly dependent on where in the Gemfile the react-rails gem is loaded. Placing react-rails at the very end of the Gemfile seems to help.
One suspect for changing the load order of initializers is the use of the after: :load_config_initializers option throughout react-rails' railtie.rb.
I couldn't find an explanation for this however Rails has removed one use of the after: :load_config_initializers option from its own active_support/railtie.rb with this comment:
Avoid to define an initializer after the load_config_initializers This make the config/initializers run before the railties are loaded what can break some configurations. https://github.com/rails/rails/commit/0a120a818d413c64ff9867125f0b03788fc306f8
Some testing of commenting out the after: :load_config_initializers options in the react-rails railtie.rb did seem to alleviate the load order issue I was seeing when loading the react-rails gem.
I've not been able to get to the bottom of this yet I'm afraid, so I'm posting this here in the hope that other developers will encounter this, add their experience, and help resolve.
Sounds like an interesting discovery. It could be good to see how other popular rails gems tie in and change to modern good practice just as a matter of course, especially if we do end up showing this is causing an issue.
@eliotsykes Were you able to verify this issue again? Closing the issue for now.
@alkesh26 Happy for this to be closed. Its been a while and I can't remember all the details I'm afraid. I think all the information and the workaround I found are detailed above.