Update to latest rubocop gems; simplify rubocop.yml #58
Conversation
By default, rubocop makes you explicitly opt in or out of new rules that are added in each release. Otherwise it loudly prints warnings to the console. This is annoying and makes updating gems tedious. In practice, we almost always end up enabling the new rules. This commit updates our rubocop config with: ``` NewCops: enable ``` This automatically opts us into any new rules that are added. That means there is no need to explicitly enable individual rules, and so our rubocop config becomes much smaller. This commit updates rubocop and rubocop-performance to their latest versions and thus enables all the new rules that have been added in those versions. The only rule that caused violations (and that I have disabled), is `Style/AccessorGrouping`.
| @@ -4,6 +4,7 @@ require: | |||
| AllCops: | |||
| DisplayCopNames: true | |||
| DisplayStyleGuide: true | |||
| NewCops: enable | |||
There was a problem hiding this comment.
This automatically opts us into new rules that are added in future versions of rubocop. So we no longer need to explicitly list the new cops with Enabled: true every time we update the gems.
| Layout/LineLength: | ||
| Max: 120 |
There was a problem hiding this comment.
This is now the default for rubocop so we don't have to explicitly specify it.
| Lint/StructNewOverride: | ||
| Enabled: true |
There was a problem hiding this comment.
Because of NewCops: enable, we no longer need to explicitly opt in to all these rules.
| Style/AccessorGrouping: | ||
| Enabled: false |
There was a problem hiding this comment.
This one caused violations in this repo so I turned it off. Enabling it would mean we would lose our ability to add comments for each individual accessor:
attr_accessor :one # Comment describing :one
attr_accessor :two # Comment describing :twoRubocop wanted:
attr_accessor :one, :two
| @@ -4,6 +4,7 @@ require: | |||
| AllCops: | |||
| DisplayCopNames: true | |||
| DisplayStyleGuide: true | |||
| NewCops: enable | |||
| TargetRubyVersion: 2.4 | |||
There was a problem hiding this comment.
I thought that this was also unnecessary... that it would default to whatever ruby version is run.
See rubocop/rubocop#5610.
Should we let the version autodetect instead? It's one fewer places to change.
There was a problem hiding this comment.
My understanding is that TargetRubyVersion can be inferred for app repos, because an app is deployed with a specific version of ruby (usually declared in the Gemfile). But for library code like socrates, we support multiple versions and so that inference can't be done. So we need to be explicit about the lowest version of ruby that this library supports.
If I remove the TargetRubyVersion line, rubocop defaults to 2.7. It is not smart enough to infer based on the required_ruby_version in the gemspec.
|
Ah, got it. And I'm having deja vu... I'm pretty sure you explained this to
me before. :) Thanks!
…On Wed, Jul 15, 2020 at 9:50 AM Matt Brictson ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In .rubocop.yml
<#58 (comment)>:
> @@ -4,6 +4,7 @@ require:
AllCops:
DisplayCopNames: true
DisplayStyleGuide: true
+ NewCops: enable
TargetRubyVersion: 2.4
My understanding is that TargetRubyVersion can be inferred for app repos,
because an app is deployed with a specific version of ruby (usually
declared in the Gemfile). But for library code like socrates, we support
multiple versions and so that inference can't be done. So we need to be
explicit about the lowest version of ruby that this library supports.
If I remove the TargetRubyVersion line, rubocop defaults to 2.7. It is
not smart enough to infer based on the required_ruby_version in the
gemspec.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#58 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGD22PZQS4L325UNBSN23R3XM3TANCNFSM4O2VA5SQ>
.
--
Christian Nelson | Carbon Five | [email protected]
|
By default, rubocop makes you explicitly opt in or out of new rules that are added in each release. Otherwise it loudly prints warnings to the console. This is annoying and makes updating gems tedious. In practice, we almost always end up enabling the new rules.
This commit updates our rubocop config with:
This automatically opts us into any new rules that are added. That means there is no need to explicitly enable individual rules, and so our rubocop config becomes much smaller.
This commit updates rubocop and rubocop-performance to their latest versions and thus enables all the new rules that have been added in those versions. The only rule that caused violations (and that I have disabled), is
Style/AccessorGrouping.