Set up reloading after_initialize

[composerinteralia]

Alternate fix for #336. We went with #347 instead because the solution
in this commit didn't work with Rails 4.2. Since we are no longer
supporting Rails 4.2, I think this is a better approach.

The original problem looked like this:

Rails runs all of the initializers

1. Run the "factory_bot.set_factory_paths"
   initializer
2. Run the "factory_bot.register_reloader"
   initializer, which sets up a prepare callback
3. Run the :run_prepare_callbacks initializer
4. This triggers the factory_bot prepare callback, which causes
   factory_bot to reload

Rails runs after_initialize callbacks

1. I18n initializes
2. factory_bot reloads again as described in Add back loading definitions in after_initialize #334

Triggering the first factory_bot reload before initializing I18n could
cause an error in some cases.

We avoided the problem in #347 by adding a conditional to skip reloading
factory_bot before the application has initialized.

This commit, on the other hand, moves factory_bot reloading from a
prepare callback into an after_initialize callback. The initialization
process is now simplified to:

Rails runs all of the initializers

1. Run the "factory_bot.set_factory_paths"
2. Run the :run_prepare_callbacks initializer, which no longer
   involves factory_bot

Rails runs after_intialize callbacks

1. I18n initializes
2. factory_bot loads definitions for the first time. It then runs the
   reloader to set up the prepare callback to reload factory_bot when the
   application reloads (for example by calling reload! in the console),
   and to register the reloader to trigger reloads when any factory_bot
   definition files change.

[dikond]

In our project (legacy) we, unfortunately, have to do something like this while defining factories:

TestArticle = Class.new(Article) do
  reset_callbacks(:save)
  reset_callbacks(:create)
  reset_callbacks(:update)
  reset_callbacks(:commit)
end

FactoryBot.define do
  factory :article, class: TestArticle do
    # definitions...
  end
end

Prior to you PR we had a nasty warnings when running the spec, e.g.

/webapp/spec/factories/articles.rb:5: warning: already initialized constant TestArticle
/webapp/spec/factories/articles.rb:5: warning: previous definition of TestArticle was here

Today I decided to trace this code and find the root cause, which led me to these two hooks registered by the factory_bot_rails: run_prepare_callbacks & finisher_hook.

I was very happy to find out that you've changed this behavior just 3 days ago. I specified the latest commit SHA (bfee5d) in our Gemfile to test it out and I can confirm that this warning no longer bothers us. So thank you very much for it @composerinteralia. May I ask when do you plan to release a new version of a gem?

[composerinteralia]

Nice! I'm glad this change is working for you. I don't think there is much holding up a 6.0 release at this point. I might be able to get it out in the next week before going on vacation.

Warnings about redefining constants within factory definition files seem to have a way of creeping back up again and again, especially if you use spring and if you use factory_bot_rails in the development environment. My recommendation would be to move the constant into its own file somewhere in test/support or spec/support, then require that file in your factory definition file. Using require will ensure that the file only gets load once, and thus that the constant only gets loaded once (whereas factory definition files potentially get reloaded multiple times with load).

[dikond]

Yeah I was also thinking about moving these test classes out of factory definitions, but it seemed like a routine task and I was much more excited to find out why it's reloaded several times (we aren't using spring).

Good that you mentioned it will be 6.0 release - I will have the time to prepare for an update if there are other breaking changes. And yeah, have a good vacation 🙂

[composerinteralia]

Released!