Config proposals #33
Config proposals #33
Conversation
Avoids misleading comment in gemspec and reflects minimally supported rubocop version.
Count arrays and hashes as one-line when calculating method and class length. We have these set in many of our internal rubocop configs so it makes sense to consider this a default preference.
As far as I know there's no reason this can't be added as a dependency to avoid the extra step in the installation instructions.
This is a shared gem that is intended to run on any version of ruby 2.7 and upwards. Including a ruby-version file seems counter to the conventions of similar gems so perhaps we should remove this.
Remove `spec/` exclude for `Metrics/BlockLength` as this is now a default in rubocop-rspec 2.11+
citizens-advice-style.gemspec
Outdated
| @@ -23,6 +22,7 @@ Gem::Specification.new do |spec| | |||
|
|
|||
| spec.require_paths = ["lib"] | |||
|
|
|||
| spec.add_dependency "rubocop", "~> 1.30.1" | |||
| spec.add_dependency "rubocop-rspec", "~> 2.11.1" | |||
| spec.add_dependency "rubocop", "~> 1.36" | |||
There was a problem hiding this comment.
It is up to 1.43 now.
There was a problem hiding this comment.
Whilst I'm not here anymore, rubocop is quite lax on versioning. So using a minor lock might give you more piece of mind. Most ruby projects do to cover themselves unless new cops come in and bust CI runs
There was a problem hiding this comment.
I was thinking we could loosen this up so we don't need a new version of this project for every rubocop update. A major lock might be sufficient.
The lock file means it won't randomly change on the consuming project.
There was a problem hiding this comment.
I'm not so sure about the major constraint, a constraint of ~> 1 is too loose. By design this is a set of conventional config. There will be options in our defaults that require a minimum version floor to be able to use them. I think the kind of pessimistic constraints we have now (at least y 1.x minor version, but not version 2) is what we want. We are only saying "at least" with these constraints so we don't need to update for every version unless we were outright pinning.
There was a problem hiding this comment.
FYI, ~> 1 is actually a bit erroneous. As such whilst it is permitted in the twiddle setting, I dislike it in all my projects and in cucumber-rails recently I got people to clean it up to the more verbose ~>1.x
For reference: ~> 1 is actually identical to >=1, < 2 (And as such it's identical to ~> 1.0 (... almost), But yeh it's maybe an issue with how ruby parses it. Hardly anyone uses it though
There was a problem hiding this comment.
Turns out I didn't understand the twiddle. Thanks Luke. So ~> 1.43 would actually do what I want. Good change!
Consider this a set of proposals for a v10 of the gem. Mostly proposing one new set of rules and updating some of the related config to get new versions and to include rubocop-rails in the gemspec.
Count arrays and hashes as one-line
Count arrays and hashes as one-line when calculating method and class length. We have these set in many of our internal rubocop configs so it might make sense to consider this a default preference.
Add rubocop-rails as as dependency and bump dependency versions
As far as I know there's no reason this can't be added as a dependency to avoid the extra step in the installation instructions. Bump all other rubocop dependencies to newer versions.
Add TargetRubyVersion to internal rubocop config
Avoids misleading comment in gemspec and reflects minimally supported rubocop version
Remove ruby-version file
This is a shared gem that is intended to run on any version of ruby 2.7 and upwards. Including a ruby-version file seems counter to the conventions of similar gems so perhaps we should remove this.