I’d say that is because Zeitwerk (Rails’ new autoloader) should load it all automatically already:
“Autoloading a constant no longer involves walking autoload paths looking for a relative match in the file system. Zeitwerk does one single pass and autoloads everything using absolute file names. In addition, that single pass descends into subdirectories lazily, only when the namespaces are used.”
Thanks @mediafinger, I guess the question is, why is it discouraged to add other root paths to autoload_paths that are outside the /app directory? In my case I had a couple of files that I wanted to have autoloaded (and reloaded) but they didn’t really fit in the /app folder. Of course I can just go ahead and do it, but I wondered why it’s not really recommended
@Spike we actually break up our monolith into small “packs” that sit at the project root. Each pack has their own set up app/* (autoloaded) directories. We inject these extra paths via Rails.application.paths['app'] << .... This as actually been working well. Only drawback is the paths that your app needs to “listen” to for changes is a lot more. Haven’t seen issues from that though.
That comment is inherited from the classic guide (commit). I imagine the reason is that pushing to autoload_paths does not push to eager_load_paths, and in the past you could not autoload in production after server boot due to limitations in classic mode.
This is no longer the case, and that guide needs to be revised for Rails 7. In Rails 7 classic mode is no longer available and the guide needs a pass.
It is true, however, that normally you want to push the directory also to the eager_load_paths to have it eager loaded, which is generally what you want. But, in any case, no problem adding your custom directories at all. Please consider that advice outdated.
Thanks everyone I was actually using eager_load_paths to bring these extra folders in pre-6.0 (due to that very issue of reloading).
I’m also using engines for the 20 or so components in my application. Works really well! And all of their app directories are autoloaded well.
Thanks for the clarification @fxn, that makes a lot of sense. That line in the docs did prompt me to reorganise things, but it’s probably for the best. Turns out most of it could be put in the app directory. The only ones that I had a hard time placing were Active Record association extensions. I made a directory off of app called extensions, but I really feel that they should be stored off of app/models like app/models/extensions but then they need to be needlessly prefixed with Extensions::. It’d probably be better to autoload that directory the same way that concerns is treated specially.