After a RuboCop upgrade, a run warns about pending cops and about `require: rubocop-performance` - what does each warning mean, and how do you fix the .rubocop.yml?

## Why an upgrade produces warnings RuboCop follows semantic versioning for its configuration. Minor releases add cops but aim not to break a green build, and changed defaults wait for a major release. Two mechanisms carry that promise, and both surface as warnings right after a `bundle update rubocop`. ## Pending cops A cop added between major versions ships in `config/default.yml` with **`Enabled: pending`**. A pending cop does not run. Instead, every run prints a list headed `The following cops were added to RuboCop, but are not configured`, with each cop's version, until the project records a decision. The options, from narrowest to broadest: 1. **Per cop** - `Lint/MisplacedMagicComment: Enabled: true` (or `false`). 2. **Per department, since RuboCop 1.90** - `NewCops` under a department key accepts `enable`, `disable`, `pending`, or a **version**. `Style: NewCops: "1.88"` enables every pending `Style` cop whose `VersionAdded` is 1.88 or earlier and keeps warning about later ones. Quote the version: YAML reads an unquoted `1.20` as `1.2`. Extension departments are pinned to the extension's own version scheme. 3. **Globally** - `AllCops: NewCops: enable` or `disable`. At `AllCops` level only the three keywords are accepted. 4. **For one run** - `--enable-pending-cops` or `--disable-pending-cops`, which override the file. A department setting beats the `AllCops` setting for that department's cops. On a **major** upgrade (1.x to 2.0) all pending cops become enabled in bulk. The one documented exception is a cop that reports configuration that silently does nothing: `Lint/CopDirectiveSyntax` was enabled in the 1.91 minor release. | Choice | Upgrade experience | Risk | |---|---|---| | `NewCops: enable` | new offenses appear in the upgrade pull request | noisy upgrades | | `NewCops: disable` | silence | useful cops never adopted; a big jump at 2.0 | | department version pin | review a batch per department | a little bookkeeping | Since `Gemfile.lock` pins RuboCop, `enable` is safe for an application: new offenses appear in the upgrade pull request, where someone is looking. A shared config gem that many teams inherit is better off pinning versions per department. `pending` is not the same as `preview`. RuboCop 1.91 added `Enabled: preview` for cops that are still experimental; `NewCops: enable` does not turn those on; `AllCops: Preview: true` or `--preview` does, and `--only` can still run one by name. ## `plugins:` versus `require:` Before 1.72 an extension such as rubocop-performance was loaded with `require:`. That simply called `Kernel#require` on the name, and the extension used an undocumented hook to inject its own `config/default.yml` into RuboCop's defaults. RuboCop 1.72 introduced **plugins**, built on the `lint_roller` library: - a plugin gem declares `default_lint_roller_plugin` in its gemspec metadata and ships a `LintRoller::Plugin` subclass; - `plugins:` in `.rubocop.yml` (or `--plugin` on the command line) loads it, and the plugin hands RuboCop its rules and default configuration through that API; - if a gem that supports the plugin API is still listed under `require:`, RuboCop prints the warning and loads it as a plugin anyway, so the fix is a config edit, not a behaviour change. `require:` is not deprecated for everything. Paths are handed to `Kernel#require`; a path starting with `.` is resolved relative to the `.rubocop.yml`, so a project's own cop in `./lib/custom_cops/no_sleep.rb` stays under `require:`. The documentation says there are no plans to remove it. ## Reading the two warnings side by side | Warning | Meaning | Fix | |---|---|---| | `The following cops were added to RuboCop, but are not configured` | pending cops exist and do not run | decide them: `Enabled`, department `NewCops`, or `AllCops: NewCops` | | `... extension supports plugin, specify plugins: ... instead of require: ...` | the gem ships a `lint_roller` plugin | move the gem name from `require:` to `plugins:` | Neither warning changes the exit status, which is why both are easy to ignore for months. A pending list that keeps growing means new checks never reach the codebase; a lingering `require:` keeps a published extension on the compatibility path RuboCop maintains for pre-plugin configurations, with a warning on every run. ## A clean upgrade routine - Upgrade RuboCop and its extensions in their own pull request. - Move every extension that prints the plugin warning from `require:` to `plugins:`. - Decide the pending cops explicitly, one by one or per department, so the list stays empty. - Run the whole suite and fix or configure the new offenses in the same pull request.