Anthropic recently added support for custom slash commands, allowing you to define commonly used prompts as reusable macros.

Based on my experience as a Ruby developer, I’ve created several custom commands for typical Ruby project workflows, such as:

• Configuring CI with GitHub Actions (including Ruby matrix builds)
• Adding RuboCop or Standard
• Bumping the Ruby version across gemspecs, Gemfiles, and CI configs
• Adding common Ruby gems with appropriate configuration

Although Claude does a reasonable job for these with a zero-shot prompt, the custom commands allow for better adherence to modern best practices, which are often preferable over what the model was trained on.

Each command has been iteratively refined based on real-world usage across different Ruby projects. (I’ve found that using bullet-point checklists makes Claude more systematic about following instructions).

As these patterns may be valuable to the broader Ruby community, I’ve published a claude_code_slash_commands gem (mostly written by Claude Code of course).

The gem provides a simple install command that copies the slash commands to your local ~/.claude/commands directory. The commands are designed with Ruby development expertise in mind, incorporating common patterns and approaches.

If you have ideas for additional Ruby-focused slash commands, I’d love to see them! Feel free to open a PR on the repository to contribute your own commands that could benefit the Ruby community.

Zed is a modern, high-performance code editor that’s gaining popularity. After several years of using VS Code, I’ve been trying it out for writing Ruby and I’ve been impressed. With recent rapid development in AI, Zed’s close collaboration with Anthropic makes it a strong contender to VS Code derived editors such as Cursor.

In this post you’ll learn how to set up Ruby LSP with Zed, and how to troubleshoot if things aren’t working. I’ll also share some alternatives for features that aren’t currently available in Zed.

Setting up Ruby Support

Zed’s Ruby support comes from the official Ruby extension, created by Vitaly Slobodin. You can enable it through zed: extensions.

As with all Zed extensions, it is written in Rust. Its documentation can be found here, as part of the official docs.

Configuring Ruby LSP

Zed has good built-in support for the Language Server Protocol, meaning there’s a lot of tooling already available that can be used.

Zed defaults to using Solargraph as its language server for Ruby, but my preference is to use Ruby LSP, since I’m a contributor.

You’ll also be able to take advantage of Ruby LSP add-ons such as ruby-lsp-rails and ruby-lsp-rspec.

It can configured in Zed’s settings as follows:

{
  "languages": {
    "Ruby": {
      "language_servers": ["ruby-lsp"]
    }
  }
}

(The docs suggest disabling each language server that you don’t want with !, and using "..." to enable the rest, but I find it simpler to just list the ones you do want).

Note: I’ve noticed that some configuration changes don’t seem to apply until you fully quit and reload the editor (workspace: reload isn’t enough), so you may need to do that in some situations.

To verify things are working, open a Ruby file, then choose debug: open language server logs from the command menu. The output should look something like this:

If there are multiple language servers running, then you’ll need to first select the ruby-lsp log from the menu at the top left.

If ever it seems that Ruby LSP is not running, this is the first place to check for errors.

Enabling Diagnostics (linting)

Update: This section previously described a workaround for the lack of pull diagnostics support in Zed, but this has now been implemented and diagnostics are working.

Disable onTypeFormatting

~There is known issue in Ruby LSP with cursor placement when trying to type a | for block arguments, so you may want to disable onTypeFormatting for now~

Update: This was changed to be disabled by default in v0.13 of the extension.

Global vs Local Settings

So far I’ve shown settings as being added to the Zed’s global configuration.

If you only ever work on a single Ruby project, then it doesn’t really matter if you all your settings are global. But many of us work on codebases with different configurations, such as for linting and formatting, so having more granular control is often necessary.

You can add project-specific settings to .zed/settings.json in your project directory. These settings will be merged with the global settings, so normally you’ll only need a few lines of configuration. For example, you might have some projects that use RuboCop but others that use Standard.

Running tests

One very useful feature when using Ruby LSP in VS Code is Code Lens, which adds a Run in Terminal link to each test, and shows the result in the integrated terminal.

This LSP feature is not supported by Zed, but we can use the powerful Tasks feature to do something similar.

For example, to add a task for running Rails tests, we can create a .zed/tasks.json file:

[
  {
    "label": "test $ZED_RELATIVE_FILE:$ZED_ROW",
    "command": "bundle exec rails",
    "args": ["test", "\"$ZED_RELATIVE_FILE:$ZED_ROW\""],
    "tags": ["ruby-test"]
  }
]

The test can be run by clicking on the ▷ in the gutter, or with the Command-Shift-R keybinding.

Advanced LSP Troubleshooting

It can sometimes be useful see the underlying requests and responses for the language server. In the debug: language server logs window, click the second menu, then enable RPC Messages:

What’s Missing

• If you’re coming from VS Code with Ruby LSP, you might notice some features are not available. There’s two main reasons behind this:

  • Some Ruby LSP features depends on custom behaviour in the VS Code extension. Those would need to be reimplemented for Zed within the Ruby extension.

  • Some parts of the LSP specification are not yet implemented in Zed. You can follow this Zed issue to learn more.

• Changes aren't indexed until Zed is restarted.

  (#3384). This is now working.

• A debugger is in beta, and there’s a PR open for supporting rdbg.

• Zed supports Snippets but the Ruby extension doesn’t yet have any. I have a PR in progress to add them.

Other Useful Resources

• For ERB linting, support for Herb has been merged and should ship soon.
• For ERB formatting, erb-formatter works well.
• To toggle between a test and its implementation, try zed-test-toggle.
• For working with Hotwire, there is the Zed Stimulus extension.
• Support for Sorbet was previously available in a separate extension but is now built-in as of v0.9.0 of the Ruby extension.

It has the ability to automatically embed transcripts into the recordings. I wanted to extract these out to use with an automated workflow for OmniFocus, a task manager.

With a little bit of investigation, I could see the transcript was represented as a Base64 string contained in JSON. Here’s how to extract it:

strings recording.m4a | tail -n 1 | sed 's/^[^\{]*//' | jq -r '._root.txscriptv2.tx._data' | base64 --decode

A brief explanation of how each command is used:

• strings to extract any text found within the file
• tail to keep only the last line (the one with the JSON)
• sed to discard the part of the line before the JSON structure
• jq to extract the specific part of the JSON containing the encoded text (the -r flag removes the quotes).
• base64 to decode it

In this post we introduce the Ruby LSP add-on system. We’ll explain the problem it solves, discuss its architecture, showcase some example add-ons, and share our vision for a future addon ecosystem that enhances the Ruby development experience.

https://railsatscale.com/2024-10-03-the-ruby-lsp-addon-system/

Since Jumpstart Pro is a commercial product, I can’t share the full code, but if you’re a Jumpstart customer you can view the changes in this branch of my fork. I recommend viewing it as individual commits to understand it step-by-step. The order may not exactly match the blog post, but the end result should be the same.

For this post, I’ll assume you are starting from a freshly generated Jumpstart app. If you have already built your app on top of Jumpstart then it may take some more effort but the overall approach is the same.

I’ll demonstrate the process in incremental steps, so your app can continue to be deployed while type information is still being added. This follows Sorbet’s philosophy of Gradual Typing.

Preparation

Start by creating a sorbet branch for the Sorbet migration. This will be fairly short-lived, and only needed for the initial setup.

Setting up CI

Although Jumpstart Pro provides a GitHub Actions CI script, we’ll instead use setup-rails since it will detect if Sorbet is in use and run additional checks. We’ll also enable the standard option, since that’s what Jumpstart uses instead of RuboCop.

name: Verify
on: [push, pull_request]

jobs:
  verify:
    uses: setup-rails/setup-rails/.github/workflows/verify.yml@main
    with:
      run-before-tests: sudo apt-get install -y -qq libvips
      standard: true

(I also had to disable parallel testing by commenting-out the parallelize line in test_helper.rb, as I found it was causing the tests to hang. I haven’t had a chance yet to look into the cause.)

Basic Setup

Overall, the setup for Jumpstart Pro is not so different than for any other Rails app, but the optional dependencies complicate things a little: If there is code that references a gem that isn’t installed, then typechecking will fail, even if it’s within a defined? check. To simplify things for this guide, we will open the Jumpstart configuration page and enable the following features:

• Payment Processor: Stripe
• Background Queue: Sidekiq
• ActsAsTenant
• Facebook Omniauth Provider

This will result in some additions to Gemfile.lock which you should commit.

Next, we’ll add the sorbet-static-and-runtime and tapioca gems to the Gemfile, run bundle then bundle exec tapioca init.

The init command can take a long time to run (10 minutes or more), and it may seem like it has frozen. Have patience!

You may be alarmed by the huge number of RBI files this creates, but you will very rarely need to interact with them.

After this is complete, we can commit everything. Let’s now run the typechecker:

$ bundle exec srb tc

We should see about 20 errors. It’s common to encounter errors when setting up Sorbet initially, usually due to known limitations in Sorbet or Tapioca.

In the case of Jumpstart, several are due potentially ambiguous definitions, which are easily fixed by using the full version of the definition. For example instead of:

module Admin
  class User::ImpersonatesController < Admin::ApplicationController
  end
end

we need to write:

module Admin
  module User
    class ImpersonatesController < Admin::ApplicationController
    end
  end
end

Other errors are because some parts of the gem are not required by default. We need to add an entry to Tapioca’s require.rb:

# sorbet/tapioca/require.rb
require "administrate/base_dashboard"

and then re-run bundle exec tapioca gem administrate.

After this there should be only handful of remaining errors, which are due to the Sorbet limitation that “include must only contain constant literals”. We can work around this by marking those calls as unsafe:

T.unsafe(self).include Engine.routes.url_helpers

At this point you can push to CI and everything should be green again. If you wish, you can merge the sorbet branch into main and continue the remaining work in other branches.

Clearing the TODO list.

Although we are no longer seeing any typechecking errors, some things are being ignored because they are listed in todo.rbi which was generated by sorbet init. We should aim to eliminate these before continuing.

We intentionally never manually edit todo.rbi - we’ll make a change, and then regenerate it, to gradually reduce the number of entries.

Many of the remaining entries in todo.rbi are due to optional gems, where they are conditionally referenced in an initializer. We could just delete those, but that would make it a little tricker pulling in changes from upstream in Jumpstart Pro. The approach I suggest is using Ruby’s __END__ keywords. It indicates that the code in the file has ended, and so Ruby (and Sorbet) will ignore it:

__END__

Bugsnag.configure do |config|
  config.api_key = Rails.application.credentials.dig(:bugsnag, :api_key)
end

Next, we have some entries in todo.rbi that relate to the Devise and Noticed gems. For gems that make use of metaprogramming, we often need to give Sorbet some help by adding shims.

# sorbet/shims.rbi
class Devise::OmniauthCallbacksController; end
class Devise::RegistrationsController; end
class Devise::SessionsController; end

class Noticed::NotificationChannel; end

For Minitest::Mock and Sidekiq::Web, we again need to add entries to require.rb then regenerate the RBIs.

# sorbet/tapioca/require.rb
require "minitest/mock"
require "sidekiq/web"

At this point, there should be no more entries in todo.rbi and running tapioca todo will delete it.

Standard

Although Jumpstart uses Standard rather than RuboCop, there are some useful cops in rubocop-sorbet, so we will add that as a dependency.

Then in .standard.yml, we’ll use Standard’s extend_config feature to reference a RuboCop Sorbet configuration file:

# .standard.yml
extend_config:
  - .rubocop_sorbet.yml

The config will look like this:

# .rubocop_sorbet.yml
require: rubocop-sorbet

AllCops:
  NewCops: disable
  Exclude:
    - lib/jumpstart/test/dummy/**/*
Sorbet/ConstantsFromStrings:
  Exclude:
    - 'app/models/connected_account.rb'

We’ll ignore the Dummy app used by the internal jumpstart gem, since that should be treated as a separate application.

We also we need to disable the ConstantsFromStrings check for one file, due to Sorbet’s limitations for const_get.

With that done, we can now run bundle exec standardrb --fix which will add a typed: false entry to each file. This happens because rubocop-sorbet’s default configuration enables the Sorbet/FalseSigil cop, which ensures all files are at a strictness of a least false.

On its own that doesn’t do anything, but it prepares the way so that we can use Spoom.

Spoom

Spoom consists of several tools, one of which is the bump command:

bundle exec spoom bump

This helps us discover which files can be ‘bumped’ up a level of typing.

You should see that a large number are now marked as # typed: true, without us having to do any work.

Next Steps

At this point, you can search for # typed: false in *.rb and you’ll see there are around 100 files remaining that aren’t yet typed. Resolving all those is outside the scope of this post, but you now have a strong starting point.

You’ll notice that we haven’t written any signatures yet. But even without those, we can start benefiting from Sorbet’s checks for things such as calls to non-existing methods, or unreachable code.

Over time, I made few updates and adjustments to it, so whenever I started a new project I would copy the config from one of my older projects. But this meant each project gradually became inconsistent, and some got updated more than others.

I wanted to have one single base workflow for all my apps, so that if I made a change, all the apps could easily benefit from it.

Reusable Workflows

In November 2021, GitHub announced that Reusable Workflows was generally available.

Although GitHub Actions has supported composite actions for a long time, Reusable Workflows allows for a much more concise configuration, and the ability to reference a whole workflow from another repository, rather than having to build up each step individually.

Read more about it on GitHub’s blog.

Introducing setup-rails

Using the Reusable Workflows feature, I’ve created setup-rails for quickly and easily enabling CI for Rails apps.

By creating a single file in your repo, e.g. .github/workflows/verify.yml, with the contents below, you should have a working CI workflow which configures the database and runs your app’s tests:

name: Verify
on: [push]

jobs:
  verify:
    uses: andyw8/setup-rails/.github/workflows/verify.yml@v1

You can take a look at this example app to see it in action.

The first time you run the workflow may be slow, but subsequent runs should be much faster once the dependencies are cached.

I’ve also shared a Railsbyte so that you can set this up with one command:

rails app:template LOCATION="https://railsbytes.com/script/VMys8A"

Principles and Configuration

I designed setup-rails so it should work at a basic level with no configuration needed for most apps.

There are a few options you can enable depending on your app, such as RuboCop, Bundler Audit and RSpec - see the README for details.

Currently only Postgres is supported but I’d like to expand to cover at least MySQL.

Enhancements

Building upon Matt’s great starting point, I made a few updates:

• Uses the latest versions of setup-node and setup-ruby
• Adds support for rails test (e.g. Minitest) as well as RSpec
• Enabled Dependabot for updates of the actions that setup-rails depends on
• Uses setup-node’s JavaScript caching rather than a custom approach
• Skips development gems when running Bundler to avoid unnecessary work.

Get Involved

I’m already using this on most of my apps, but I’d love to get wider feedback.

Please try setup-rails on your app and let me know how it works for you. Issues and pull requests are welcome!

I noticed that whenever I was starting on a new kata, I was doing the same basic setup repeatedly before being able to write a first test. I also felt I was missing some of the configuration that my other ‘real’ projects benefited from.

This led me to create ruby-kata-template. By clicking on Use this template, I get a new blank project in seconds, configured to my preferences.

I don’t expect my preferences to match everyone else’s, so I encourage you to fork it and customize to your own ideal template.

Features

Starting Point

There is an empty Project (project.rb) and a corresponding test (project_test.rb). I expect the first step in many katas will be to rename these.

Directory Structure

I’ve followed the standard Ruby convention of the implementation being in lib/ and the tests in test/

Minitest

Although Minitest is already provided as a Bundled gem with Ruby, it’s included in the Gemfile to ensure we’re on the latest version. (I’ve used RSpec extensively in the past, but my current preference is Minitest).

ActiveSupport::TestCase

ActiveSupport::TestCase is part of Rails but here we are using it independently. It allows you to write ‘declarative’ tests, e.g. test "it works" do... rather than def test_it_works, which I feel is more readable.

Rake Task

It’s common on Ruby apps to have rake or rake test, so we provide that. It has support for both MiniTest naming conventions (test_*.rb and *_test.rb)

Standard

Standard is an opinionated RuboCop configuration.

For me, the real value of Standard (or RuboCop) is only apparent when you have two things configured in your editor:

• Immediate feedback (your editor highlights problems as you code)
• Auto-formatting (you can fix issues with one single shortcut, or automatically when the file is saved).

There are various ways to set up this, but the template uses rubocop-lsp.

rubocop-lsp

rubocop-lsp is a gem which implements the Language Server Protocol. It allows for a close integration between your editor with RuboCop. It avoids the overhead of starting RuboCop, meaning linting or auto-correction is near-instant.

To use it, you’ll also need an plugin or extension for your editor. The template is set up to recommend the VS Code Shopify.rubocop-lsp extension.

Solargraph

Solargraph adds IDE-like experience for your editor. It provides helpful features such as a content-aware autocompletion, and documentation for the Ruby language.

However, I often run into problems with it, so I was on the fence about including it.

It’s not as powerful as Sorbet, so it’s unable to infer types unless they are a Ruby primitive (String, Array, etc.)

And more

Take a look at the README to learn what else is included.

A failing build is demoralizing and disruptive for the team. Developers and testers will lose confidence in the correctness of the system. They may be unable to know if a failing test was due to their change, or to something else.

Keeping the master build passing should take priority over almost everything else. The whole team should feel responsible for it, and when the build fails, the whole team should be alerted. It shouldn’t be left to a ‘devops’ team, or only to senior developers. One option is to configure your CI to post notifications to your team’s Slack channel for high visibility.

We can adopt several practices to help ensure master stays passing:

• Performing code reviews to detect potentially problematic tests
• Running linters to catch common problem areas, such as rubocop-rspec
• Using features such as GitHub Checks to enforce a passing build before the branch can be merged into master.

But even with these practices, things can still go wrong:

• We can have intermittent failures due to factors such as time of day or concurrency.
• We can have a semantic conflict, where behaviour is correct on individual branches but incorrect when they’re combined.
• We can have infrastructure failures unrelated to the code.

It’s important to establish a clear process for what should be done when the master build fails. The details of this should be discussed and agreed by your team, but I’ll discuss one starting point.

In most cases, the most recent merge will be the one that broke the build. If the author of the most recent merge hasn’t reacted to the failure, send a gentle nudge.

The first thing the author should do is pull the latest master, and check if the test passes locally. If it fails, that gives a good starting point. If it passes, we’ll have to broaden the investigation.

While this in progress, there are two key things to keep in mind:

• Getting the build back to passing as soon as possible
• Keeping the team informed, and sharing an ETA if feasible

If the team isn’t aware of work going on, a developer might assume that a failure was due to their change. Or another developer may start investigating the failure, unaware that someone else is already on it. Both could result in wasted time.

The next step is more nuanced. It may need discussion with the team, and could depend on the nature of your project:

• Should you revert?
• Should you temporarily disable the test?
• Should you delete a flawed test?

Have a clear written policy for this is useful, for example in your wiki or README.

If the fix is going to take some time to resolve, you should aim to give updates at least every hour or so.

Once the problem is resolved, take some time to reflect. Was there a particular practice which caused this? Could you make some change to improve things? There’s almost always some learning opportunity.

The de facto tool to use for this is cron. It’s somewhat archaic, but provides a reliable mechanism to declaratively define job schedules. The popular whenever gem provides an DSL to make this easy to use with Ruby.

Simple tasks such as clearing a cache are a great match for cron. They run quickly and don’t require significant system resources.

The difficulty comes when cron is used to execute tasks which rely on the Rails application. It’s easy to make use of cron for this, because we can call the rails runner command to invoke a method on a class.

On a small app, this approach may be fine, but when scaling up there are some serious drawbacks.

Whenever we use rails runner, we’re launching a completely separate instance of the application. Let’s say your Rails app typically uses around 200MB of memory. To allow for some growth, we provision a server with 512MB of memory. If you schedule a cron job, the server’s memory usage will temporarily spike to around 400MB.

This might not even be noticed at first. Even if the machine runs short on memory, it can temporarily make use of swap space on disk. This might happen in the middle of night, when traffic is already low.

But consider what happens once you have more scheduled jobs:

• CalculateUsage runs daily at 2am
• GenerateReports runs weekly at 2am (every Monday)
• CreateInvoices runs monthly at 2am (first Monday of each month)

This means that once a month, all three jobs will be triggered at the same time. Your system needs to have enough capacity to run three instances, in addition to the main app.

This could mean you need to over-provision your servers by 4x. That extra capacity will be idle most of the time. On a large site, you could be spending thousands of extra dollars per month. Or if you don’t sufficiently provision, then you risk crashing your site.

This risk is often exacerbated by the nature of scheduled jobs. A web request typically lasts only for a few seconds at most. But a job may run for a much longer period, causing a large spike in memory use.

A First Approach

Let’s take a step back, and consider how we schedule jobs. Is it critical that each jobs runs at 2am? Probably not. The key thing probably that the job is complete by the beginning of the business day.

A common first reaction to this problem is to try ‘pad out’ the jobs to prevent them overlapping. For example, instead of running each job at 2am, you run the first at 2.00am, the next at 2.05am, and the next at 2.10am.

While this may provide a short term fix, it’s not a sustainable solution. As your data grows, the time it takes to run each job will creep up, and will start to overlap again. You’ll end up playing Whac-A-Mole shifting jobs around.

A Better Approach

As with many scaling problems, we can handle growth better if we can scale horizontally and add additional machines.

We can achieve this with a distributed queue. In Rails, we typically use tools such as Sidekiq, Resque or Delayed Job.

We could even configure this to auto-scale to handle varying workloads.

Instead of using cron to execute the jobs, we’ll use it to only enqueue them, e.g.:

job = MonthlyReport.new(Date.today)
Delayed::Job.enqueue(job, queue: 'cron')

We’ll also benefit from built-in support for retries, although this does require some care to write jobs which are idempotent.

This approach still involves booting up a separate Rails instance, but it’s a fast operation. Spacing jobs one minute apart should be sufficient to prevent overlaps.

You may later run into another problem of timeouts from jobs being too large. That can often be handled with a map-reduce approach, but that’s beyond the scope of this post.

Further Improvement

Instead of having to boot up an instance of the app just to enqueue a job, there’s another approach we can take.

We can add an internal API endpoint, such as /api/internal/jobs. We can make an HTTP post, specifying the job to be enqueued. That means cron only needs to execute a call to something like curl, which uses vastly less resources. Obviously you should add some kind of authentication or restriction on the endpoint to avoid any possibility of a DOS attack.

If you use rspec-rails, and your app has been around for more than a few years, the chances are that your rails_helper.rb has accumulated a lot of cruft. This increases the time it takes to run a single test, probably to several seconds at least. As this usually happens gradually, it often goes unnoticed by those who work in a codebase every day. Developers may become accustomed to waiting ten seconds or more to run a single test.

The default rails_helper.rb generated by the rspec-rails installer is minimal and fast. There are a variety of things which tend to be added which slow it down:

• Seeds tasks (such as from seed_fu).
• Requiring of all files within spec/support (older versions of rspec-rails defaulted to this but this approach is now discouraged by the RSpec team).
• Global RSpec hooks such as Before and After
• Libraries to manage database state, such as DatabaseCleaner
• Setup for browser testing tools, such as Capybara
• Miscellaneous other testing support libraries.

Some of these will have a much bigger impact than others. You can use profiling tools to better understand the contribution of each.

Overview

The key to speeding up the TDD cycle is to only load what’s needed for a specific test. This strays from Rails’ convention of having everything auto-loaded, but I would argue it’s a worthwhile trade-off.

(Note that this will probably not have any impact on your overall test suite time. The focus here is on the time for running an individual test or test file).

Refactoring your whole test suite at once could take some time, perhaps several days for a large app. We want to do it gradually, in small steps, so that test suite stays green. Here’s how.

Implementation

First, we rename the existing rails_helper.rb to something like legacy_rails_helper.rb.

We then update the existing references to that file with the new filename, which should be a simple global search and replace in your editor.

Run your tests suite to ensure everything is still passing.

Next, we create a ‘clean slate’ rails_helper.rb. An easy to do this is by re-running the rspec-rails generator, i.e. rails generate rspec:install.

Now, find a relatively basic test in your test suite. It’s usually easier to start with focused unit tests rather than integration tests, since they typically have more dependencies.

Change the test to run with the new rails_helper.rb. If it passes, then great, we’re done.

Note that it’s important to verify that the tests passes individually. If you run the whole suite, a previously run test may have already loaded a necessary dependency. Since RSpec runs the tests in a random order, this may result in a false positive.

But what if the test fails? Often the test output will indicate that the failure is due to a missing dependency.

There are a few courses of action you can take to resolve this:

• You can determine what lines in legacy_rails_helper.rb are needed, and copy them to your rails_helper.rb.
• You can use custom hooks so that particular lines are only executed for tests that are tagged with that hook name.
• You can copy only what’s required for that specific test.

Let’s talk about the pros and cons of each.

If we always copy the code back into rails_helper.rb then we’ll end up close to where we started. So we should reserve that for dependencies which are used in a large number of tests, e.g. something like FactoryBot.

What about hooks? RSpec lets us run specific code for tests with a particular tag:

RSpec.configure do |config|
  config.before(:db) do
    require "some-library"
  end
end

This can be useful, but the downside is that we’re adding a layer of indirection. A developer reading the test would need to know what a particular tag represents.

The last approach is to be explicit about each test’s dependencies, for example:

require "rails_helper"
require "some-library"

While this might result in a little more typing, it’s an effective way to manage dependency loading.

Communicating the Change

If you’re working on a team, you’ll want to ensure that while the changeover is in progress, new tests are written using the new rails_helper.rb. This is something you could also add to your project’s README or developer documentation so that others joining the team are also aware. You could also use a custom RuboCop check.

Final Steps

Eventually, you’ll have moved every test over to the new rails_helper.rb. You can now delete legacy_helper.rb. You may also discover there gems in your Gemfile which are no longer needed, and can be dropped. You may also be able to remove unused files from spec/support if they are no longer referenced.