Are you that person? I confess I studied Autoloading and Reloading Constants guide several times. But I still make those autoload mistakes.

Let’s face it – Rails autoloading is hard. You need to be constantly aware of it. And sometimes even that is not enough.

So if your app uses autoloading its broken anyway, and mutant will not support “rspec triggered autloads” anymore.

Why bother with mutation testing if you cannot correctly self initialize ;)https://t.co/10nTlWqZtA

— Markus Schirp (@_m_b_j_) July 17, 2018

Have you ever changed your design only to satisfy Rails autoloader behaviour? Coping with it requires constant bending to the rules how your files are structured. Not only the namespacing, but also the directory structure 😱

TIL: Rails autoloader creates modules based on directory names. 😱😂

a/b/c.rb

…creates A::B for me, even if I don’t want it.

— Nick Sutterer (@apotonick) December 15, 2016

Are you familiar with to_prepare and in control of objects initialization? Have you already changed relevant requires to require_dependency?

Both @dry_rb and @trailblazer_to have problems with Rails autoloading, so maybe it could be solved once and for all, pretty please? @fxn 😍https://t.co/kJx3u7u1fq https://t.co/95zTFtqvrb

— Nick Sutterer (@apotonick) January 13, 2018

There is life with Rails without autoloading! For a long time I’ve lived with the presumption that this is the only way in Rails. You can escape The Rails Way but autoloading will catch you in the end. It turns out I was wrong. Life without autoload is possible. And it is eye-opening how different it is!

The first thing I do on touching rails codebases to rescue them is disable all autoloads, and force deterministic (full) eager loads.

— Markus Schirp (@_m_b_j_) June 7, 2017