Can someone please point me in the right direction for the order in which rails modules get instantiated.
The main things I'm trying to find are:
1) When do gems get loaded?
2) When do config/initializers/* get loaded?
3) When do named routes in routes.rb get processed?
Answering your question is easy by adding some puts statements in your Rails application. (It seems like a lot of people are reluctant to dig in and do this, but I really recommend it!) So, by experimentation and observation alone, here is the order of the things you mentioned:
boot.rb
config/initializers/*
routes.rb
Here is a little more detail:
1. boot.rb
This loads the application gems by using bundler:
require 'rubygems'
# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)
require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])
2. config/initializers/*
They run in alphabetical order.
If you are curious what triggers this, take a look at engine.rb in the railties source code. (It is useful to know that a Rails Application is a subclass of a Rails Engine.)
initializer :load_config_initializers do
config.paths["config/initializers"].existent.sort.each do |initializer|
load(initializer)
end
end
3. routes.rb
By observation, I see that route drawing (specification) occurs next.
But looking at the details is more involved, so if you are interested I would read SO: Controlling routes loading order from Engines and perhaps take a look at the :add_routing_paths initializer in engine.rb.
Check out this insanely detailed (and long) piece of documentation on the initialization process:
http://guides.rubyonrails.org/initialization.html
I started a console in Rails 3 and here is the order:
script/rails
config/boot.rb
config/application.rb
config/environment.rb
config/initializers/*.rb (In alphabetic order)
I really don't know but logically in this order
gems
initializers
routes
1) The only way I know how to edit gems is by editing the source file themselves. Moreover rails itself and basically everything with rails is a gem so I'm sure they are loaded first
2) Initializers are probably loaded second, or at least considering the three things you mentioned, because they might load information or modules that routes with resources and associations need.
3) Process of elimination
In terms of inner order it's probably abc
Don't take this seriously though :)
Related
This issue relates to a need to set a Rails config variable as the application boots, and the value of that variable needs to come from data in the database (which are then modified). So, I have an initializer with something like this:
require "#{Rails.root}/lib/modules/facet_altering.rb"
include FacetAltering
Rails.application.config.reject_subjects = FacetAltering.reject
The reject method is potentially slow and calls the Subject model (which includes some concerns).
If I try to require subject.rb, application_rb and the relevant concerns from app/models then I progress a bit further, but eventually get stuck on uninitialized constant Subject::MySpecialConcern.
There might be some better way to set the reject_subjects value; I'd prefer not to run FacetAltering.reject each time the value of reject_subjects is used, though this might be an easy 'fix' if no other solution arises (at the cost of slowing things down). Or, is there another way to access these classes as the application boots?
Edit: Following on from the comment below, this is in config/application.rb:
%W[#{Rails.root}/lib/modules #{Rails.root}/test/mailers/previews].each do |path|
config.eager_load_paths << path
end
This post offered a useful clue:
Rails Model no longer available in initializer after upgrade to Rails 7.0
So, putting my code in config/application.rb as follows did the trick:
config.after_initialize do
Rails.application.config.reject_subjects = FacetAltering.reject
end
Now to find the answer to RuntimeError: Foreign key violations found in your fixture data. Ensure you aren't referring to labels that don't exist on associations. and I might be able to complete this Rails 6 -> 7 upgrade!
I have a brand new Rails 6 app and without anything in the config/routes.rb, the output of bin/rails routes has a massive list of very long urls for ActiveStorage, Action Mailbox, and conductor.
This is making bin/rails routes completely useless as a form of documentation, especially since the options for bin/rails routes don't allow filtering out things.
I don't want to omit these parts of Rails as I may need them. But I would prefer these routes a) not exist if I'm not using them and b) not show up in bin/rails routes.
Does anyone know how to make this work?
As of Rails 6.0.2.1, this is the way to do it:
In config/application.rb, remove the line require "rails/all" and replace it with this:
# See https://github.com/rails/rails/blob/v6.0.2.1/railties/lib/rails/all.rb for the list
# of what is being included here
require "rails"
# This list is here as documentation only - it's not used
omitted = %w(
active_storage/engine
action_cable/engine
action_mailbox/engine
action_text/engine
)
# Only the frameworks in Rails that do not pollute our routes
%w(
active_record/railtie
action_controller/railtie
action_view/railtie
action_mailer/railtie
active_job/railtie
rails/test_unit/railtie
sprockets/railtie
).each do |railtie|
begin
require railtie
rescue LoadError
end
end
Note that if you leave actiontext in, you still get a few active storage routes included. Not sure why. This configuration basically means you cannot use active storage, action text, or action mailbox. Bringing those back in will bring back many routes you will never need.
Also note this solution has a carrying cost because with each Rails version upgrade, you must examine rails/all.rb to make sure no new frameworks were added that you might care about (or removed that you no longer should be requiring).
You can have the ActionMailbox routes omitted by commenting out the specific require line in your application.rb.
Specifically if you comment the require "action_mailbox/engine" line you'll no longer see any of the /rails/action_mailbox or /rails/conductor/action_mailbox routes.
You'll need to restart the app for the changes to take affect.
I'm in the process of refactoring some logic built into a Rails application into middleware, and one annoyance I've run into is a seeming lack of convention for where to put them.
Currently I've settled on app/middleware but I could just as easily move it to vendor/middleware or maybe vendor/plugins/middleware...
The biggest problem is having to require the individual files at the top of config/environment.rb
require "app/middleware/system_message"
require "app/middleware/rack_backstage"
or else I get uninitialized constant errors on the config.middleware.use lines. That could get messy very quickly. I'd rather this was tucked away in an initializer somewhere.
Is there a conventional place to put this stuff?
The specific answer I'm looking for with this bounty is: where can I put the require lines so that they are not cluttering the environment.rb file but still get loaded before the config.middleware.use calls? Everything I have tried leads to uninitialized constant errors.
Update: Now that we're using Rails 3.0, I treat a Rails app like any other Rack app; code files for middleware go in lib (or a gem listed in Gemfile) and are required and loaded in config.ru.
As of Rails 3.2, Rack middleware belongs in the app/middleware directory.
It works "out-of-the-box" without any explicit require statements.
Quick example:
I'm using a middleware class called CanonicalHost which is implemented in app/middleware/canonical_host.rb. I've added the following line to production.rb (note that the middleware class is explicitly given, rather than as a quoted string, which works for any environment-specific config files):
config.middleware.use CanonicalHost, "example.com"
If you're adding middleware to application.rb, you'll need to include quotes, as per #mltsy's comment.
config.middleware.use "CanonicalHost", "example.com"
You can put it in lib/tableized/file_name.rb. As long as the class you're trying to load is discoverable by its filename, Rails will automatically load the file necessary. So, for example:
config.middleware.use "MyApp::TotallyAwesomeMiddleware"
You would keep in:
lib/my_app/totally_awesome_middleware.rb
Rails catches const_missing and attemts to load files corresponding to the missing constants automatically. Just make sure your names match and you're gravy. Rails even provides nifty helpers that'll help you identify the path for a file easily:
>> ChrisHeald::StdLib.to_s.tableize.singularize
=> "chris_heald/std_lib"
So my stdlib lives in lib/chris_heald/std_lib.rb, and is autoloaded when I reference it in code.
In my Rails 3.2 app, I was able to get my middleware TrafficCop loading by putting it at app/middleware/traffic_cop.rb, just as #MikeJarema described. I then added this line to my config/application.rb, as instructed:
config.middleware.use TrafficCop
However, upon application start, I kept getting this error:
uninitialized constant MyApp::Application::TrafficCop
Explicitly specifying the root namespace didn't help either:
config.middleware.use ::TrafficCop
# uninitialized constant TrafficCop
For some reason (which I've yet to discover), at this point in the Rails lifecycle, app/middleware wasn't included in the load paths. If I removed the config.middleware.use line, and ran the console, I could access the TrafficCop constant without any issue. But it couldn't find it in app/middleware at config time.
I fixed this by enclosing the middleware class name in quotes, like so:
config.middleware.use "TrafficCop"
This way, I would avoid the uninitialized constant error, since Rails isn't trying to find the TrafficCop class just yet. But, when it starts to build the middleware stack, it will constantize the string. By this time, app/middleware is in the load paths, and so the class will load correctly.
For Rails 3:
#config/application.rb
require 'lib/rack/my_adapter.rb'
module MyApp
class Application < Rails::Application
config.middleware.use Rack::MyAdapter
end
end
I'm not aware of a convention, but why not put it in the /lib directory? Files in there get automatically loaded by Rails.
You could create an initializer which requires the necessary files and then leave the files wherever you want.
According to this the initializers are executed before the rack middleware is loaded.
The working solution I have so far is moving the middleware requires to config/middleware.rb and requiring that file in environment.rb, reducing it to a single require which I can live with.
I'd still like to hear how other people have solved this seemingly basic problem of adding middleware to Rails.
I am facing an issue where my Rails application is set to cache classes when run in the staging or production environment. While load_paths only contains 'app/models', it appears that the initialization steps recursively caches everything in 'app/models'.
# Eager load application classes
def load_application_classes
if configuration.cache_classes
configuration.eager_load_paths.each do |load_path|
matcher = /\A#{Regexp.escape(load_path)}(.*)\.rb\Z/
Dir.glob("#{load_path}/**/*.rb").sort.each do |file|
require_dependency file.sub(matcher, '\1')
end
end
end
end
The problem in this is that we have a sub directory within 'app/models' that contains files with require statements that reference a concurrent JRuby environment. Since Rails knows nothing of this environment our application breaks on load.
As it stands, here are the proposed solutions...unfortunately only #1 is ideal.
1) The simplest solution would be to exclude the culprit sub directory, but have not found anything how to accomplish this.
2) Monkey patch the load_application_classes method to skip the specific sub directory.
3) Move the sub directory out from under 'app/models'. Feels a bit hackish and would require quite a few code changes.
Thoughts?
As a temporary measure you could go with a version of option 2 and override the definition of load_application_classes, replacing it with an empty implementation. That would force you to explicitly require the classes you need but it would give you complete control over what gets loaded and would be a completely transparent solution.
It sounds like your application is sufficiently sophisticated that it's growing beyond the Rails framework. I know that this doesn't directly answer your question so appologies in advance but you may want to consider looking at an alternative Ruby framework like Merb. Rails is great but sooner or later you bump into edge of the framework - sounds like that's where you are now.
We made the switch to Merb last year and haven't regreated it.
Chris
Just as an example, if I have a Book model and a BooksController, autotest, part of the ZenTest suite will pick up the association between the two and load test/unit/book_test.rb and test/functional/books_controller_test.rb into the test suite. On the other hand, if I have a Story model and a StoriesController, autotest refuse to "notice" the test/functional/stories_controller_test.rb
Unfortunately ZenTest isn't a rails plugin, so it doesn't benefit from ActiveSupport's pluralize method. Therefore it uses simple regular expressions to match the filenames. Have a look at ZenTest/autotest/rails.rb to see a list of the existing mappings for Rails.
At the end you have two options:
(monkey) patch your own mapping rule
forget about pluralization
Hope this helps!
You can override the mappings in your .autotest file. Either in your home directory or at the root of the project. You could require 'active_support' there to get String#pluralize and String#singularize.
Borrow the code from the rspec-rails plugin in lib/autotest/rails_rspec.rb, it already seems to do the singular/plural magic with ActiveSupport. You'll probably need to yank out the RSpec specific assumptions from there, though.
I finally figured out what was going on, and it had nothing to do with pluralization after all.
It had everything to do with the word "stories" which can be a special directory for one of the testing libraries (RSpec? Cucumber? I forget) So it was listed in my ~/.autotest config file as an exception! I'm not sure when I cut and pasted the snippet into the file, probably when I was first getting starting with ZenTest and didn't know what I was really doing.
Autotest.add_hook :initialize do |at|
%w{... stories ...}.each {|exception|at.add_exception(exception)}
end
Adding a trailing slash ("stories/") restored the test and removed the brick marks from my forehead.
So I guess the lesson learned is: check for stray configuration files when debugging.