In my experience the level of coupling between your components depends on your design, writing require calls won’t make your design better or worse, it is your head that keeps the design clean as time evolves.
But that approach might not be for everyone, if you prefer to write your code using that system that is totally fine, just do it.
That is why Zeitwerk is designed in a way that allows each gem and application to have their own independent loader. In addition to saving authors from writing requires within the gem, clients don’t need to write them either. Well, except for the require of the main gem file, which is issued by Bundler normally.
Gems not using Zeitwerk need requires as usual.
Hey Chris, maybe some hacky one, but I have not tried. ActiveSupport::Dependencies is in charge of this and you’d need Zeitwerk to take over.
The plan is to have it integrated in the second beta if it makes the cut.
The main benefit is adherence to Ruby semantics, which eliminates some issues in the current Rails autoloader.
Since autoloading is builtin into Rails, this gem is not just a drag & drop, for existing projects some monkey patching would be needed probably.
Hey Alex! Long time!
I wouldn’t say it is superior, but let me explain a bit in any case.
At first glance, some differences that I see in features that seem to be common to both gems are that require_all seems to be greedy traversing the tree structure, whereas Zeitwerk is lazy, it does not descend…
To me, the distinction between compilers and interpreters is a bit blurred.
For example, Ruby, Perl, or Python have compilers, they generate bytecode that gets executed by a virtual machine. Perl semantics explicitly have language constructs that happen at compile time vs runtime.