Recently upgraded an application to Rails v6.1.4 and have been using zeitwerk. It doesn’t seem like Rails runs zeitwerk:check on startup so would it fail at run time if it tried to load something that was incorrect? Or is this only because I’m doing it in my development environment and it would fail in a production environment?
Either way, a way to avoid this is adding zeitwerk:check as a pre-commit hook in my git repo to help other contributors not commit bugs on accident. Wondering if this is good practice or an unnecessary check?
All that zeitwerk:check does is eager load the environment. So you are correct that in production, if you had a class that would fail the check, the app would fail to boot. In development, eager load is turned off, so you would only run into the problem if you happened to run across a path that tries to load the problematic class.
Thanks, that makes sense. It’s probably worth it to add it as a commit or pull request check then because I don’t want to wait until prod deploys to find out.
Yeah, eager loading could always potentially fail. The file could not define the expected constant, or it could have a syntax error, or have a typo in class-level code.
Note we are talking about non-tested code, though. If the file has test coverage, Zeitwerk already validated it. Zeitwerk validates all autoloads, and zeitwerk:check eager loads because eager loading is a recursive autoload, so that triggers those validations (Zeitwerk is a client of itself).
If you want to play safe just in case some file sneaks in without test coverage, enabling eager loading in CI may be a safety net. Rails 7 has something in that line in the generated config/environments/test.rb.
