* Changed: Layout/IndentationWidth cop enabled by default
* Changed: Use the new `Cop::Base` API instead of the deprecated `Cop::Cop`
* Removed: support for Ruby 2.6
* Removed: deprecated config files for RuboCop < 0.68
* Remove version constraint on actionview so we can test against a more
recent version
* Stop testing against EOL Ruby 2.6 (latest actionview doesn't support
Ruby 2.6)
* Run `bundle update` to bump as much as possible
Maintaining a separate "edge" config and "legacy" config probably served
us well [back around the time we were migrating to rubocop
0.68](d533765dcd),
but it's not working well for us anymore. Things changed often before
rubocop 1.0, and there are versions out there that don't work perfectly
with either of these configs (see
https://github.com/github/rubocop-github/pull/86, for example).
This commit sets a version constraint for rubocop ">= 1.0.0" and deletes
the `*_deprecated.yml` files that only worked with rubocop <
0.68. With the deprecated files deleted, it also consolidates the
remaining files into default.yml and rails.yml.
This commit bumps all development dependencies, and removes pessimistic
version constraints where possible now that we've got a Gemfile.lock checked
in.
We had to keep the constraint for Rails for now, since Rails 7 is not
compatible with Ruby 2.6. We can bump Rails if we drop Ruby 2.6.
None of this affects the released gem, so as long as tests still pass we
are in good shape.
These constraints make it more difficult to upgrade these libraries in
projects that use rubocop-github.
I think the idea here was that we'd be able to bump the version
alongside the default config, but without locking to an exact version we
can still end up with a config that is incompatible with certain rubocop
version (see the unrecognized cop error in
https://github.com/github/rubocop-github/pull/86, for example).
If anything, I'd prefer a `>=` constraint over a `<=`. That would allow
us to bump the minimum constraint when we add new cops, but still
freely upgrade in our projects as long as there are no config
incompatibilities (which are less common anyway ever since RuboCop 1.0).
Version 1.4 of rubocop introduced a breaking change that creates some
warnings and issues when using `parser/ruby27`, this issue was fixed in
https://github.com/rubocop/rubocop/pull/9702 and released in 1.13.0
This is a breaking change. To get this to pass CI
I had to delete the 'Lint/EndInMethod' cop, which has
been renamed to 'Style/EndBlock'. Since we already had
Style/EndBlock, I deleted rather than renaming the old
cop.
This is a breaking change.
To get this to pass CI, I have done the following:
* deleted performance cops
* renamed a Metrics/LineLength to Layout/LineLength
* deleted another Metrics/LineLength
The performance cops appear to have been extracted into a separate gem,
https://github.com/rubocop-hq/rubocop-performance and as of 0.78.0
referencing them without including the rubocop-performance gem as a
dependency blows up.