Skip to content

Add AllowedPredicates configuration option to Rails/Env#1617

Open
dduugg wants to merge 2 commits into
rubocop:masterfrom
dduugg:rails-env-allowed-predicates
Open

Add AllowedPredicates configuration option to Rails/Env#1617
dduugg wants to merge 2 commits into
rubocop:masterfrom
dduugg:rails-env-allowed-predicates

Conversation

@dduugg
Copy link
Copy Markdown

@dduugg dduugg commented May 11, 2026

Summary

Replace Rails/Env's hard-coded ALLOWED_LIST constant with a configurable AllowedPredicates option. The default value is the previous ALLOWED_LIST content — String / StringInquirer predicates like empty?, match?, between? — so out-of-the-box behavior is unchanged.

The motivation is to let users exempt additional predicates from the cop without forking or disabling it. Two concrete cases this addresses:

  • Rails.env.local? — the built-in alias for "development or test", introduced in Rails 7.1. Some users treat it as a legitimate guard rail for code that should only ever execute in dev or test (sanity checks, devtools, seed data) rather than as an environment-rollout mechanism, and want it exempt from the cop.
  • Custom predicates monkey-patched onto the environment inquirer. Apps with their own Rails.env.beta_user? / Rails.env.internal? style helpers can now opt those in.

The configured value fully replaces the default — it is not merged. Users who want to inherit the defaults and add to them can opt in via RuboCop's inherit_mode:

Rails/Env:
  AllowedPredicates:
    - empty?
    - match?
    - local?

Compatibility with Rails/EnvLocal

Rails/EnvLocal autocorrects Rails.env.development? || Rails.env.test?Rails.env.local?. Under the default AllowedPredicates, Rails/Env will still flag the autocorrected Rails.env.local?. Users who run both cops can now resolve that conflict by including local? in their AllowedPredicates rather than disabling either cop.

Test coverage

A new context block uses let(:cop_config) to override AllowedPredicates and verifies (a) a predicate in the override is not flagged, and (b) a predicate omitted from the override is flagged — confirming the override is exhaustive (no implicit merge with defaults).

Before submitting the PR make sure the following are checked:

  • The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (no related issue).
  • Feature branch is up-to-date with master.
  • Squashed related commits together.
  • Added tests.
  • Ran bundle exec rake default.
  • Added an entry to the changelog folder.
  • If this is a new cop, consider making a corresponding update to the Rails Style Guide (N/A — existing cop).

Replace the hard-coded `ALLOWED_LIST` constant with a configurable
`AllowedPredicates` option. The default value preserves the previous
behavior — `String` / `StringInquirer` predicates such as `empty?`,
`match?`, and `between?` are still exempt out of the box — but users
can now customize the list, for example to allow `Rails.env.local?`
or a custom predicate monkey-patched onto the environment inquirer.

The configured value fully replaces the default; users who want to
inherit the defaults and add to them can opt in via RuboCop's
`inherit_mode`.

  Rails/Env:
    AllowedPredicates:
      - empty?
      - match?
      - local?

A new spec block uses `let(:cop_config)` to verify that overriding
`AllowedPredicates` both allows the configured predicate and continues
to flag predicates that are no longer in the list.
@dduugg dduugg force-pushed the rails-env-allowed-predicates branch from 6dc5bea to b7b27ad Compare May 11, 2026 17:57
@dduugg dduugg marked this pull request as ready for review May 11, 2026 18:07
@corsonknowles
Copy link
Copy Markdown

Great fix! Thanks for the added versatility.

And we need this now as well, because we do allow .local?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants