启用zeitwerk后重新加载时未初始化的常数

Question

在完成从经典到Zeitwerk的迁移时遇到了一些困难。

启用zeitwerk并运行rails s之后，一切似乎都正常了。然后，在保存了一个.rb文件并刷新之后，我看到了一个“未初始化常量”错误，当我试图从顶级/lib中请求一个文件时。

有些东西配置错了，但是我正在抓我的头，想弄清楚细节。我当时的印象是，拥有一个顶级的/lib文件夹很好，并且使用require在该目录中加载文件与Zeitwerk兼容，但现在我不太确定.关于我做错了什么的想法？

注意:我目前没有设置任何特定的eager_load_paths或autoload_paths

编辑:按照@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'

Answer 1

名称空间CustomModule在可重新加载的项目中共享(在app下)，也在不能加载的部分中共享(在lib下)。

这很好，它是支持的。您只需要考虑加载优先级，因为如果lib定义了CustomModule::Foo，Rails认为CustomModule是可重加载的，那么在重新加载时没有人再次加载CustomModule::Foo，而require是幂等的，因此不会再找到CustomModule::Foo。

解决方案是确保lib定义名称空间，Rails自动加载程序重新打开它。本质上与文档化的这里相同。这可以通过在初始化器中发出require来完成，例如，初始化器从lib加载名称空间。

这样，当自动加载程序扫描文件系统时，它知道它不负责管理CustomModule。它会下降的。如果有子常量，那么一切都将像往常一样工作，这些常量将被重新加载，但是名称空间本身不会。