2

Having some trouble working out the migration from Classic to Zeitwerk.

After enabling zeitwerk and running rails s, everything seems to work. Then after saving a .rb file and refreshing, I'm seeing an "uninitialized constant" error when trying to require a file from the top level /lib.

Something is misconfigured w/ reloading, but I'm scratching my head trying to work out the details. I was under the impression that having a top level /lib folder is fine and using require to load files in that directory is compatible with Zeitwerk, but now I'm not so sure... ideas as to what I'm getting wrong?

Note: I'm not currently setting any specific eager_load_paths or autoload_paths

EDIT: updated with logging output as suggested by @Xavier

Zeitwerk@rails.main: module CustomModule autovivified from directory *********/app/workers/custom_module
Zeitwerk@rails.main: autoload set for CustomModule::Profiler, to be loaded from *********/app/workers/custom_module/profiler.rb
Zeitwerk@rails.main: autoload set for CustomModule::AnotherProfiler, to be loaded from *********/app/workers/custom_module/another_profiler.rb

NameError - uninitialized constant CustomModule::AttributeParser
Did you mean?  NameParserConstants:
  app/models/user.rb:180:in `first_name'
  app/middleware/catch_json_parse_errors.rb:8:in `call'
  app/middleware/decompress_requests.rb:22:in `call'
Roy Kolak
  • 605
  • 1
  • 6
  • 18
  • Yes, it is compatible. Could you please throw `Rails.autoloaders.log!` in `config/application.rb`, trigger the error, and share the traces? – Xavier Noria Mar 04 '22 at 09:48
  • Ah! you know what... there's a `CustomModule` defined in `/app/workers` and a `CustomModule` defined in `/lib`. Looks like the `/app/workers` version is loading last and appears to be overwriting the version in `/lib` – Roy Kolak Mar 04 '22 at 15:22
  • Exactly, is a case of https://github.com/fxn/zeitwerk#reopening-third-party-namespaces. The `require` is idempotent, the constant is reloaded, so child constants from the namespace defined in `lib` are no longer reloaded. You need to define `CustomModule` during boot, so that the autoloader knows it does not manage that namespace (it descends automatically). – Xavier Noria Mar 04 '22 at 19:44

1 Answers1

7

The namespace CustomModule is shared in parts of the project that are reloadable (under app), and also in parts where is not (under lib).

This is fine, it is supported. You only need to deliberately think about load priorities, because if lib defines CustomModule::Foo and Rails believes CustomModule is reloadable, on reload nobody is loading CustomModule::Foo again, and require is idempotent, so CustomModule::Foo won't be found anymore.

The solution is to make sure lib defines the namespace, and Rails autoloaders reopen it. Essentially same as documented here. This can be done by issuing a require in an initializer that loads the namespace from lib, for example.

That way, when the autoloader scans the file system, it knows it is not responsible for managing CustomModule. It will descend. If there are child constants there everything will work as usual, and those constants will be reloaded, but the namespace itself won't.

Xavier Noria
  • 1,640
  • 1
  • 8
  • 10
  • Thanks for the detailed explanation! I ended up just altering one of the module’s names (and folder) to avoid the confusion – Roy Kolak Mar 05 '22 at 22:21
  • That's a great solution, less dragons and no need for an artificial `require` to force load order. – Xavier Noria Mar 05 '22 at 22:59