RuboCop 2.0 roadmap

[pirj]

Some ideas outlined by Bozhidar in a blog post:

• Make RuboCop significantly faster (e.g. 2 times faster than it currently is). Think of it as our version of Ruby 3x3.
• Organize cops into some “presets” that would address the common complaint that RuboCop checks for way too many things out of the box. Think of this as something like an “essential”, “standard”, “community style guide”, “github”, “rails”, “all-in” and so on configuration bundles that enable different cops. It’s not like you can’t do this today, but probably shipping this out-of-the-box would simplify the setup for many people. There are plenty of interesting ideas to explore in this direction.
• Internal consistency. Make the configuration uniform and more intuitive across the board. I have to admit that in the early days of RuboCop I didn’t think much about configuration consistency, which was a major mistake on my part.

I'd coin one idea to the list:

• Make sure the enforced styles of all cops reflect the real-world usage.
  The reason is outlined in this comment. Basically, the current enforced style causes 4x more offences than an alternative style. This goes against the following mission statements:

Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide.
A style guide that reflects real-world usage gets used, while a style guide that holds to an ideal that has been rejected by the people it is supposed to help risks not getting used at all - no matter how good it is.

On the one hand, it would be quite appealing if 2.0 was a release with groundbreaking features.
On the other hand, it's been more than 1.5 years since RuboCop 1.0 release. Presently, there are 60 cops in Enabled: pending status. Except for those with the NewCops: enable "brave early adopter" setting, this would put a major burden during upgrade to RuboCop 2.0.

I'd stress releasing early, and postpone the performance improvements to a minor version.
And 2.0 will be a festive release presenting 60 fresh recruit cops. With extensions to supposedly follow the major release with 18 new cops in rubocop-rails and 10 new cops in rubocop-rspec.

There are a few tickets in the 2.0 milestone, mostly related to breaking (not ground-breaking) changes.

[pirj]

Speaking of the "significantly faster (e.g. 2 times faster than it currently is)" goal. I bet that this can be achieved by switching to lib-ruby-parser. While it's in its early stages, we can influence it to make its interface closer to parser's for easier adoption. I guess there might be good reasons for this has to be a part of major RuboCop release.
Can we smoothen the transition somehow so that well-known extensions/custom cops won't break if we'd make a switch in a minor version?

[bquorning]

In my opinion, the main benefit of a faster startup time is that I can run rubocop in an after-save hook in my editor, or in a before-commit hook in git. In those cases I will usually only be running against a handful of files, which means that the startup time is a significant portion of the total time spent.

[bbatsov]

Yes, exactly. Startup time is critical for editor integration when you're typically analyzing/correcting a single file.

[dvandersluis]

Yeah agreed here too

[pirj]

Speaking of autoload #10750

[coding-red-panda]

Isn't that related to this old discussion: https://bugs.ruby-lang.org/issues/5653

[bbatsov]

Make sure the enforced styles of all cops reflect the real-world usage.

I certainly like this, although we'd have to build first a list of proposed changes for 2.0 on this front. Perhaps we can also disable some of the more controversial cops that people have been complaining about. Generally for me the presets were mostly an incentive for us to analyzing the current defaults and improve them.

I certainly don't want to solve all the problems that exist in RuboCop 2.0, so I'm open to cutting some release sooner, provided there are going to be meaningful gains for the end users from whatever breaking changes we decide to do. Let's see how the others feel about the road to RuboCop 2 as well.

[coding-red-panda]

Organize cops into some “presets” that would address the common complaint that RuboCop checks for way too many things out of the box. Think of this as something like an “essential”, “standard”, “community style guide”, “github”, “rails”, “all-in” and so on configuration bundles that enable different cops. It’s not like you can’t do this today, but probably shipping this out-of-the-box would simplify the setup for many people. There are plenty of interesting ideas to explore in this direction.

I really like this idea.
I've been building a gem for internal usage at our company that does exactly this.
The levels are sort of divided up like game levels : novice, expert, intermediate etc.
Each level activating a very specific sub-set of Cops and keeping everything else disabled.
This allows teams to slowly adop the RuboCop rules as they implement and cleanup more code smells from their code, or agree on a consensus as to what the configuration should be.

[pirj]

This seems to be approximately something that standard does to my best knowledge. And it's a matter of creating gems with a default configuration. Those various configs can be in the same repo with RuboCop, or separate. But to my understanding, those config presets don't have to appear in 2.0 specifically.

[bkuhlmann]

In case it helps, I'd like to provide a counter-argument. Since I'm the maintainer of Caliber -- and because my team and I are very aggressive about staying on top of the latest RubCop changes -- I'm not sure adding complexity to RuboCop in terms of picking various styles helps. Instead of introducing that maintenance burden, it might be wiser to simply point to gems like Caliber so people have alternative solutions/examples instead? This doesn't reduce the burden for maintainers, like me, but does allow others to discover alternatives/presets like mentioned above.

[AlexWayfer]

Presently, there are 60 cops in Enabled: pending status. Except for those with the NewCops: enable "brave early adopter" setting, this would put a major burden during upgrade to RuboCop 2.0.

Is it NewCops really about "early access", "beta testing"? I'd like to see it enabled by default in RuboCop 2.

[pirj]

It is easy to understand if you take a look at the changelog.
Imagine, you're on 1.29.0. There's a fix for a nasty bug in 1.29.1. And there's a new cop in 1.30.0. And another fix for an old cop in 1.30.1. You want both fixes, but you don't want the new cop.

[AlexWayfer]

Hm… I guess if you want new cops (you've updated to 1.29) and bug fixes (1.30.1), then you've to be prepared for new cops, But… OK, your decision.

[bkuhlmann]

Yeah, I've been struggling with the use of NewCops as well within the Caliber gem. I don't enable the NewCops but aggressively -- and individually -- turn them on/off with each minor release. I can get away with this because the gem has not reached a 1.0.0 version as of yet -- this is basically the same predicament that prevented RuboCop from reaching a 1.0.0 version for many years -- but due to this practice I'm not sure Caliber will ever be able to reach a 1.0.0 version due to all of the reasons Phil points out above (because that would break Semantic Versioning).

[pirj]

There exists another strategy that we haven't considered. The development of new features (cops) is done on a next branch. Early adopters use that branch (similar to having NewCops turned on), or just gem releases. Those who don't want new cops just yet follow current, and the previous gem version patch releases. Fixes are merged to both the current and next.
I believe this is a simplified model of what e.g. Rails does. A downside of this is that fixes don't always apply to both branches, and need to be adjusted.

This approach puts an additional burden on maintainers:

• adjusting fixes for the next branch
• merging to both
• double the releases
• as per Rails experience, sometimes fixes are forgotten to be merged to one of the branches

RuboCop went a different route, and it appears that the majority is satisfied.

[dvandersluis]

In my experience, a multi-branch strategy ends up being better on paper than in practice. My preference would be to not go down that route.

Whether we change the default value of NewCops or not, I think there's a disconnect about Enabled. It shouldn't be "bad" to disable cops that don't mesh with the style you want but I've encountered plenty of devs who get frustrated that a cop is enabled that causes them friction. I'm not sure if there's a communication issue to be resolved here or if the maintainers' view of enabling/disabling differs from the community's view.

[AlexWayfer]

(I'll post different thought as separate posts, to be able discuss separately, sorry to bothering)

Also I'd think about inherit_mode: merge as default, as intuitive one:

inherit_mode:
  merge:
    - Include
    - Exclude

[pirj]

There is an open PR to merge Exclude, included in 2.0 milestone. I support your suggestion to add Include.

[Drenmi]

Organize cops into some “presets” that would address the common complaint that RuboCop checks for way too many things out of the box.

I have a presets proof of concept, but the branch is, I think, 3 years old now, so might no longer be usable. 😅

Make sure the enforced styles of all cops reflect the real-world usage.

I'm a bit weary about this giant can of worms as this might invite the entire internet to unleash their pent up opinions on what the defaults should be (I think it gives people some sort of validation they are "right" about something mostly subjective.)

Maybe if we decide that there's no debate, but whatever causes the fewest offenses in real-world is the default that might not be such a bad idea.

There's a huge chore for people to upgrade if they have to manually figure out the old defaults and replicate them in their configuration files though.

[Drenmi]

Another thing that came to mind is when we implement presets, we should remove library-specific configuration like this from the default configuration. 🙂

[pirj]

We did this in rubocop-rspec. Now, it is possible for a third-party library to add their configuration that end users can include. E.g. action_policy.
The downside of this approach is that it's not plug-n-play. Users have to explicitly specify that they want to use those extensions in their project .rubocop.yml:

inherit_gem:
  action_policy: config/rubocop-rspec.yml

I'd be pleased to know of a better approach. Still with a possibility for end users to opt-out, but opt-in by default.

[pirj]

And 2.0 will be a festive release presenting 60 fresh recruit cops.

68 new cops to the moment. If extensions follow with major releases, also 50 new cops from rubocop-rails, and 14 new cops for rubocop-rspec. 132 new cops total for a quite typical project using Rails and RSpec.

With 395 enabled core cops, 65 in rubocop-rails, and 84 in rubocop-rspec, total 544, that's nearly 25% more cops.

[andyw8]

I've shared a proposal for a different approach than presets:

Enable new cops on a quarterly cadence starting with RuboCop 2.0