Consider `Rails.env` checks to be an anti-pattern.

[ioquatix]

We would like to prevent something if Rails.env.production? type of code leaking into our code base. Specifically, we'd prefer that it's configuration driven, as in:

# bad
if Rails.env.production?
  add_job
end

# good
if Config.add_jobs?
  add_job
end

So we see Rails.env.(environment)? as an anti-pattern.

We have been trying out some proof-of-concept:

module Cop
  class EnvironmentCheck < RuboCop::Cop::Cop
    def_node_matcher :environment_check, <<~PATTERN
      (send (send (const nil? :Rails) :env) $_)
    PATTERN

    def on_send(node)
      environment_check(node) do |method|
        add_offense(node, message: message(method))
      end
    end

    private

    def message(method)
      "Using conditional logic like Rails.env.#{method} is an anti-pattern. Please replace with configuration specific to an environment."
    end
  end
end

[tejasbubane]

Can you explain a bit why Rails.env is an anti-pattern? To me this seems like a project-specific choice and to be honest, I don't see a reason to add this to rubocop-rails. However you can add a custom cop to your project.

[pirj]

There was a problem recently on my current project. We were making checks for Rails.env.production? in data migrations. However, we use a different environment to run migrations, and it points to a production database. We ended up having records purposed for staging in our production database.

[andyw8]

This also relates to the Config aspect of The Twelve-Factor App pattern:

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

https://12factor.net/config

[lulalala]

Not sure if this is a valid case: we had a return if Rails.env.development? logic deep in our call. When I changed a part of my code, this part of the code was never executed locally. We only found it would cause issues on production.

[Earlopain]

I understand why you wouldn't want to use Rails.env predicates in code (and in fact do not want to do the same myself) but I feel like the amount of code that does it anyways a bit too high. I have this github code search: https://github.com/search?q=lang%3Aruby+%2FRails.env%5C..*%5C%3F%2F+path%3A%2Fapp%2F**%2F*+-is%3Afork&type=code

and it gives me ~16k results. I included just app/**/*.rb in that search, usage in config and others is fair I think.
Rails by itself already has ok support for custom configuration with Rails.configuration.x but I don't think everyone should definitly use it. The problem for me is that resolving the the cop warning is not trivial, and depending on the app not even necessary.

There's a PR to implement this actually, #1375, and I shared some of my concerns about it there already.