Where is rails source code

The Rails libraries each follow the conventional structure of a Ruby Gem. This means that the gems follow these patterns:. The lib folders holds the functionality of the Rails library. While each Rails library will have completely different classes and modules within them, they each share a similar lib structure at the top level.

The fire level in lib holds a file named after the library. This file is where the library begins when you require it. You will see a list of names of the classes and modules in the Rails library and see how they are loaded through eager loading and autoloading.

If you are not familiar Eagerloading and Autoloading , this is a great opportunity to learn how it works and see which files are eagerloaded vs. This folder will contain the files for the classes and modules of the code. One file to call out in this folder is the railtie. The railtie file contains the configuration defaults for the library as well as setup for the initializers and rake tasks for the library. This file gives you a ton of information on the configuration options available within a library.

This folder holds the generators for the Rails library. For instance, this is where you will find the generator for Active Record like rails generate migration or rails generate model. With a basic understanding of how the code is structured in Rails, this section goes through strategies that I consider as helpful for familiarizing yourself with the code.

If you want to run the code locally, you will first need a copy of the Rails source code. The tests can allow you to better understand how the code flows and works together. I like to start with digging through the modules or methods that I have used and am familiar with. Doing this, I find new ways of using those methods or modules, and I see what their code is actually doing.

As an example, I wanted to better understand how controllers work, so I started with the render method in a controller. Note: If the render code peaks your interest in how controllers work, check out my RailsConf talk on that subject. In order to dig into the methods and classes you know, you have to know how to find them.

Here are three approaches that I like to take:. The documentation in these files is what makes up the docs on the api. The website allows you to search by method or class, and it provides you with the documentation for the method as well as a quick view of the source code and a link to the code on GitHub. The API docs site is usually my quickest way of finding source code, unless I already know where the code lives.

The official API site, api. The documentation can be helpful for straightforward methods, but it can be less useful for methods where the codes is spread across several modules. Code splitting among modules is a common pattern in Rails for more complex methods. He shares several tactics that he uses when debugging Ruby using simple puts statements, with some basic examples and some more complex ones.

Ruby has a special method called method that provides you with an object containing info on where a certain method lives, what it looks like, and who it belongs to. The create method is a good straightforward method to look at. Methods like create are easy to find and understand because the code lives in one place. But, in much of the Rails code, certain methods have their code split throughout Rails modules that encompass the overall method behavior.

The save method is an example of this. With save , the code is spread through different modules of Active Record: one for running validations, one for managing database transactions, all the way up to one actually doing the saving. The code starts in one module and makes its way through the other modules with super.

This is where we can use the other methods provided by the Method object. They will help us see the modules involved in save and the order that they go through.

Below is a little script example of the information we can get from the Method objects. The output provides us with the modules and the order that they run in for the save method of a model. We can see that save goes through Suppressor , Transactions , Validations , and then it finally lands in Persistence. When I find certain areas of code to be hard to read, I like to use Pry-Byebug. For a quick run through of how to step through code with Byebug, check out the Debugging section of the Ruby on Rails guides.

I use these scripts to quickly test out certain Rails methods, and I often use my local repo as the source of the Rails gem so that I can dig through the code a little easier. Bundler allows you to specify the location of a gem, rather than grabbing the gem from rubygems. I often like to use my local Rails repo to debug. In order to use it in a script, I can specify the gem as:.

This allows you to use the git repository of Rails, rather than limiting you to versions in rubygems. The Bundler docs show you several ways to use a git repo in your Gemfile, including how to use a branch or specific commit. In these cases, I find both git and GitHub to be helpful for providing additional context. The blame feature in both Git and GitHub allow you to connect a line of code with the commit that introduced the code.

First, I will give you a piece of important code. Rails :: Server. Actually, 'Rails. Rack server will start 'Rails. So let's look at it. Let's step into Rails. It is not an object. To answer this question, we need to look back to config. Initialize the Rails application. But where is the call method? The call method processes every request.

Here it is. It is invoked by Rack. So it is very important. So YourProject::Application. Let's look at the definition of instance. This line confused me at the beginning. Rack server will start Rails. And you'll only have one Rails. Multiple threads in a puma process shares the Rails. Part 2: config The first time we see the config is in. Serves out a single Rack app. This method support HTTP Keep-Alive so it may, depending on if the client indicates that it supports keep alive, wait for another request before returning.

It is just the Rails. Rack need a call method to process request. It is initialized when 'config. It's typical rack app to use these middlewares. These are some typical superclasses of HomeController. Callbacks allow you to trigger logic during this cycle. I will answer this question later. For more information, see. You will get the result html after invoking 'view. This method ensures a template is compiled just once and removes the source after it is compiled.

So re-check the compiled flag to avoid re-compilation return if compiled if view. This means we can get the template back. It's time to answer the question before: How can instance variables like users defined in HomeController be accessed in.

I will answer this question by showing the source code below. Nov 8, Feb 5, Replace webpack with importmapped Hotwire as default js Aug 26, Mar 16, Sep 8, Sep 6, Aug 20, Make Webpacker the default JavaScript compiler for Rails 6 Oct 1, Dec 18, Updated links from http to https in guides, docs, etc.

Mar 9, Jan 20, Rails 7. Oct 20, Relax dependency on Zeitwerk 2. Oct 21, Bump license years to [ci skip]. Jan 1, Preparing for 7. Sep 15, Oct 19, Update missing Rails mailing list URLs. Aug 29, Use frozen string literal in root files. Aug 13, Add spell checking with codespell as a GitHub Action.

May 4, Install JavaScript packages before run test. Feb 11,