Add AllowedPredicates configuration option to Rails/Env

[dduugg]

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).

Great fix! Thanks for the added versatility.

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

@Earlopain can you help us get this across the line? @fxn had asked us to support .local? but we didn't push that change upstream before it was merged.

The approach here allows everyone to adjust the cop accordingly so they can keep Rails/EnvLocal and also extend the behavior as needed

It would be really convenient to have local?. As the description says, there are cases in which you want to 1) be intentional about the environments, 2) rule out completely anything else. In such cases, the behavior is not configurable, really, it has to be that way, conceptually hard-coded.

can you help us get this across the line

Sorry, you would be better to get the attention of a maintainer. I haven't done any rubocop this year.

I'm not sure a public option like AllowedPredicates is needed here. Would it be sufficient to just add local? to the existing ALLOWED_LIST constant?

I'm not sure a public option like AllowedPredicates is needed here. Would it be sufficient to just add local? to the existing ALLOWED_LIST constant?

Thanks @koic, I put together that approach here:

• Allow Rails.env.local? in Rails/Env #1638

I'm not sure a public option like AllowedPredicates is needed here. Would it be sufficient to just add local? to the existing ALLOWED_LIST constant?

I could live with that, though I would like to be able to drop the other allowed predicates (it’s slightly silly to ban production? while allowing start_with? 🙈). It would also be a breaking change for dependents that want to continue disallowing local?.