Question

This is how a typical config/environments/*.rb file begins:

MyApp::Application.configure do
  config.cache_classes = false
  ...
end

The block passed to configure dereferences the symbol config which is apparently unbound. How does this technically work? The symbols used in a block/Proc/lambda should be bound in the context of its declaration, not left to be resolved in the dynamic scope at the call site.

A related question is, where exactly is the Application.configure method declared? It’s not in either application.rb, engine.rb, or railtie.rb. Maybe if I managed to find this method, I would have found the answer to my main question.

Also related, I have studied the Rails initialization procedure in excruciating detail, and I can’t find even a mention of a config/environments/*.rb file. If I knew how these files were treated by the init procedure, that may shed some light on this.

Answer 1

It’s a method config in Rails::Application in the railties gem in lib/rails/application.rb which returns an instance of Application::Configuration, defined in lib/rails/application/configuration.rb.

The method configure is contributed to Railtie from the autoloaded module Configurable, lib/rails/railtie/configurable, and is defined as

def configure(&block)
  class_eval(&block)
end

which explains why the block that configure accepts can resolve the config symbol. Note that class_eval is another piece of rubyist magic that makes this work: it rebinds the passed-in block’s self symbol to the call site’s class.

Check the comments in the first file in the Booting Process section, which explains where, how and in what order all this goodness comes from, including how the /config/environments directory is processed.