-
-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new Rails/Env
cop
#1375
base: master
Are you sure you want to change the base?
Add new Rails/Env
cop
#1375
Conversation
3a45198
to
65bf185
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. I agree with the general idea of what the cop is about but question if it should be enabled by default.
Checking the env directly seems like a somewhat common thing to do, and resolving the offense is not trivial. I can also see how some would just not care about feature-flags or similar at all, especially smaller applications. You did write in your issue that this is explicitly about large apps. In my opinion the cop should be opt-in instead.
Rails.env.capitalize
is a offense, can be used to display in a dashboard of sorts. I think it probably fine to only display warnings for predicate methods.
@Earlopain That makes sense that the cop should be opt-in. I changed the config default from |
@Earlopain after looking into more predicate methods on |
Hm, yeah. That's a good point there. I don't particularly like the solution, But I don't believe there is precedence for overarching configuration like that. So, I'd just leave it like you have it now. Though I think your list includes a cusom core extension? require "active_support/all"
("".inquiry.methods - Object.instance_methods).select { |m| m.to_s.end_with?('?') }
=> [:unicode_normalized?, :exclude?, :empty?, :acts_like_string?, :include?, :is_utf8?, :casecmp?, :match?, :starts_with?, :ends_with?, :start_with?, :end_with?, :valid_encoding?, :ascii_only?, :between?] Methods like that seem fine to not appear, as long as the common ones like |
@Earlopain The allow list isn't my favorite solution either but I'm not sure what a better solution would be. I'll defer to your decision about overreaching in configuration. I updated the allow list to be yours and confirmed I had the same list of predicate methods in a more vanilla rails app. |
This looks good to me, I have no more comments. I'm not a maintainer, so in the end the harder decisions are (luckily) not up to me (: |
@Earlopain is there workflow I'm missing to get this properly approved? I read https://github.com/rubocop/rubocop-rails/blob/master/CONTRIBUTING.md and think I'm following all the steps. Do I need to request from someone specifically or am I missing a step that you're aware of? You're my only point of contact in this repo so far 😅 |
Sorry for the late response, I forgot. You didn't miss anything, it's just that adding new cops here can be a bit of a slog. If you look at the currently open PRs, most are for new cops. Can't give you anything other than being patient I'm afraid. |
Add new
Rails/Env
cop to discourage code paths from checking Rails.env.environment?Closes #1376
This Rubocop rule is relevant to the following Rails Style Guide rules as it encourages people to use the solutions instead of checking
Rails.env.environment?
Dev/Test/Prod Configs
Staging Like Prod
YAML Config
Before submitting the PR make sure the following are checked:
[Fix #issue-number]
(if the related issue exists).master
(if not - rebase it).bundle exec rake default
. It executes all tests and runs RuboCop on its own code.{change_type}_{change_description}.md
if the new code introduces user-observable changes. See changelog entry format for details.