In a Gemfile, what does putting gems inside `group :test do ... end` declare, and what does `require: false` on a gem change?

## Groups are labels on dependencies Every `gem` line in a **Gemfile** produces a dependency with a list of **groups**. Bundler assigns them in three ways: - A gem declared outside any group gets the group **`:default`**. - A block, `group :test do ... end`, tags every gem inside it; `group :development, :test do` tags them with both. - An option on one line, `gem "rspec", group: :test` or `groups: [:development, :test]`, does the same for a single gem. Here is the Gemfile of a small JSON API with test-only gems: ```ruby source "https://rubygems.org" gem "sinatra", "~> 4.2" gem "puma" group :development, :test do gem "rubocop", require: false end group :test do gem "rspec", "~> 3.13" gem "rack-test" gem "webmock", require: false end ``` ## What groups are used for Group names matter to two consumers: 1. **Installation.** A production image does not need RSpec. The `without` setting (for example `bundle config set --local without development test`) tells `bundle install` to skip those groups. A group block declared with `optional: true` works the other way round: its gems are skipped unless the `with` setting names it. 2. **Loading.** `Bundler.setup` and `Bundler.require` accept group names, so code can put only some groups on the load path or require only some of them. What groups do **not** do is create separate bundles. The gemfile(5) man page is explicit: on `bundle install` Bundler downloads and evaluates *all* gems to build a single canonical list, so you cannot list different versions of the same gem in different groups. Even a skipped group is still used to resolve versions; that is what guarantees the production server runs the same versions you tested with, minus the groups it left out. ## What `require:` controls The `require:` option only matters to **`Bundler.require`**, the call some applications make at boot to require every gem in the named groups (with no arguments, the `:default` group). For each dependency it decides which file to require: | Declaration | What `Bundler.require` does | |---|---| | `gem "sinatra"` | `require "sinatra"` (the gem's name) | | `gem "rack-test"` | tries `require "rack-test"`; on a `LoadError` for that path it retries `require "rack/test"` | | `gem "redis", require: ["redis/connection/hiredis", "redis"]` | requires each listed file in order | | `gem "byebug", require: true` | same as the default: the gem's name | | `gem "rubocop", require: false` | requires nothing | The dash-to-slash retry exists only for the default: when `require:` is given explicitly and the file fails to load, Bundler raises `Bundler::GemRequireError` instead. ## What `require: false` does not change `require: false` is **not** an install switch. The gem is still resolved, recorded in Gemfile.lock, installed, and placed on the load path by `Bundler.setup`. Only the automatic require is skipped, so this still works in a spec helper: ```ruby require "webmock/rspec" ``` Typical reasons to use it: - **Command-line tools** such as RuboCop, which the application never loads. - **Gems with side effects on load**, such as a library that patches the HTTP client as soon as it is required; you want that only inside the test process, at a moment you choose. - **Gems whose entry file is not the one you need**, when you would rather require a sub-file explicitly. - **Boot time and memory**: every autorequired gem is loaded into every process that calls `Bundler.require`, including consoles and background workers. In an application that never calls `Bundler.require` and simply writes its own `require` lines after `require "bundler/setup"`, the option has no effect at all. ## Traps - Assuming gems in `:test` are absent from Gemfile.lock; every group is locked. - Using `require: false` to keep a gem off production machines; that is the job of the `without` setting. - Expecting `require: "rack/test"` to be necessary for a dashed gem name; the default retry already covers it. - Declaring the same gem in two groups with different requirements, which raises a `GemfileError`; declare it once with `groups: [...]`.