c0d91a4f9d
The main interface to eager loading is config.eager_load. The logic that implies happens during the boot process. With the introduction of Zeitwerk, application code is loaded in the finisher as everything else, but in previous versions of Rails users could eager load the application code regardless of config.eager_load. Use cases: * Some gems like indexers need to have everything in memory and would be a bad user experience to ask users to conditionally set the eager load flag. * Some tests may need to have everything in memory and would be a bad experience to have the flag enabled globally in the test environment. I personally feel that the contract between this method and the entire eager loading process is ill-defined. I believe this method is essentially internal. The purpose of this patch is simply to restore this functionality emulating what it did before because rethinking the design of this interface may need time. |
||
---|---|---|
.. | ||
bin | ||
exe | ||
lib | ||
test | ||
.gitignore | ||
CHANGELOG.md | ||
MIT-LICENSE | ||
railties.gemspec | ||
Rakefile | ||
RDOC_MAIN.rdoc | ||
README.rdoc |
= Railties -- Gluing the Engine to the Rails Railties is responsible for gluing all frameworks together. Overall, it: * handles the bootstrapping process for a Rails application; * manages the +rails+ command line interface; * and provides the Rails generators core. == Download The latest version of Railties can be installed with RubyGems: * gem install railties Source code can be downloaded as part of the Rails project on GitHub * https://github.com/rails/rails/tree/master/railties == License Railties is released under the MIT license: * https://opensource.org/licenses/MIT == Support API documentation is at * https://api.rubyonrails.org Bug reports can be filed for the Ruby on Rails project here: * https://github.com/rails/rails/issues Feature requests should be discussed on the rails-core mailing list here: * https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-core