Detecting unused routes with Rails 7.1

Glen Crawford
November 15, 2022

When looking at upcoming major releases of projects like Ruby on Rails, it can be easy to get distracted by the big, flashy features, such as Hotwire and encrypted attributes in Rails 7.0. However, sometimes I find myself getting more excited by smaller, more modest additions in upcoming releases. This is the case with the recent merge of a PR to Rails that will form part of Rails 7.1: Add routes –unused option to detect extraneous routes by Gannon McGibbon.

We all know the rails routes command which lists all the routes in your app, detailing their name, HTTP method, path, controller and action. But in a large app with lots of routes that might have seen a rewrite or two or a few years of churn, how do you know which routes are still valid (where “valid” means the controller and action that the route points to exists)?

Introducing the new `--unused` option (full command: `rails routes --unused`).

From an implementation point-of-view, essentially all it does is iterate over Rails.application.routes and select the ones that are unused, where “unused” is defined by this pleasingly succinct method:

def unused?
  controller_class_missing? || (action_missing? && template_missing?)

The output will be in the same familiar format as the main rails routes command which you have seen a million times before. Also note that we can filter the resulting routes to those that match a specific pattern with the -g (grep) option.

The motivation discussed in the pull request seems to be to improve the performance of your application’s boot time, routing time and memory use, since routes can be expensive to draw in terms of both time and memory. While all this is certainly true, preventing the drawing of unused routes is only going to provide a noticeable performance improvement in large apps. For me, the real benefits are in preventing routes from being left behind during refactors that remove their companion controller and/or action, and forcing developers to be more specific about their routing code, in particular when using high-level declarations like resources.

When adding a new controller to your app, it is very easy to simply add, for example, resources :posts to your routes file even when you might really only plan on initially implementing the index and show actions, possibly thinking that you might eventually use all of the seven routes that such a line will draw. While not being specific about the routes you are actually using is handy in that it allows you to come back and implement the remaining actions without having to edit your routes file at a later date, it’s possible that you’re not going to, meaning that (in this scenario) you just left behind five unused routes in your app. By periodically checking for unused routes and narrowing them down to only the ones that are pointing to implemented controller actions (by specifying the only or except options) you prevent these unused routes from accumulating and causing performance issues, dead code and confusion over time.

After all, an unused route isn’t really all that different from a method that is no longer called (or never was). Once Rails 7.1 is out, use rails routes --unused to keep on top of these and prevent them from accumulating over time. I will be.