Uninitialized constant GoodJob::JobsController

[mdavidn]

I can consistently break good_job's code reloading in my app, confirmed in Rails 6.1 and 7.0.

I never need good_job to reload its code while my application is running, so it's not clear to me why zeitwerk is a runtime dependency. #87 didn't shed any light on this. Perhaps it should be a development dependency?

Steps to reproduce

1. Create a new Rails app
2. Add good_job, mount engine
3. Start and wait for server
4. Make any change to application code
5. Try http://localhost:3000/good_job.

gem install rails
rails new good_job_demo --database=postgresql
cd good_job_demo
bundle add good_job
bin/rails generate good_job:install
bin/rails db:create db:migrate
cat <<RUBY > config/routes.rb
Rails.application.routes.draw do
  mount GoodJob::Engine => 'good_job'
end
RUBY
bin/rails server

open http://localhost:3000/good_job # Confirm working, optionally

touch config/routes.rb # or app/controllers/application_controller.rb 
open http://localhost:3000/good_job # Broken

[bensheldon]

@mdavidn thank for opening this issue. I'll try to reproduce it.

btw, I don't think the problem is Zeitwerk. GoodJob uses Zeitwerk as a convenience to avoid writing require statements in lib (not code reloading); controllers are autoloaded/reloaded by Rails via the Rails Engine (not that I presume to understand how Engines work).

[bensheldon]

@mdavidn sorry to not follow up earlier. In #677, I removed Zeitwerk entirely. Could you see if the latest release of GoodJob fixes this problem for you?

[morgoth]

@bensheldon it fixes the issue for me mentioned in #646

[mdavidn]

@bensheldon I confirmed this morning that 3.4.1 does not have this issue.

Rails::Engine does provide a hook to add paths to the Zeitwerk loaders managed by Rails, but I would be reluctant to modify global inflectors in a gem. Explicit requires may be the best approach. (The behavior matching app/* is eager_load_paths.)

[bensheldon]

Thank you @morgoth and @mdavidn!

I'm ok with explicit requires. Maybe I'll try to figure out where would be an appropriate place to open up a Zeitwerk issue (not sure if it's Rails or Zeitwerk), because I think what I previously had should have worked because my gem's Zeitwerk loader instance was only watching my gem's lib and not app (which is managed by Rails Zeitwerk loader).