Rubocop-rspec: Retire `RSpec/InvalidPredicateMatcher`

Created on 17 Jun 2020 · 4Comments · Source: rubocop-hq/rubocop-rspec

In that case, won’t RSpec tell you about the mistake? Something like

expected something to respond to `available??`

As far as I remember, according to our non-goals (a rather incomplete version of what we have in mind) it's not our business to notify the user about things that RSpec will notify with a spec failure, warning, or an error.

I clearly understand that with the editor integration it may highlight this problem earlier.
On the other hand, we don't provide auto-correction anyway.

It's an interesting topic of what we should keep, and what to retire, as this cop might be helpful for some people in some circumstances, but in general, it's not the goal of RuboCop RSpec.

WDYT @bquorning @Darhazer ?

Discussion

Source

pirj

All 4 comments

I stand by my comment in https://github.com/rubocop-hq/rubocop-rspec/pull/441#issuecomment-321885705:

👎 IMHO, Rubocop is not the right tool for solving this problem. The extra ? at the end of the predicate matcher is a typo, and as all (well, most) other typos it will be caught during runtime.

As for the “editor integration” argument, that opens the door to catch a lot of “typo” class offenses that I really think we shouldn’t bother with.

bquorning on 17 Jun 2020

👍1

I guess in the early days when there were not so many cops, all kinds of checks were accepted. Now we can choose wisely.

On the other hand, do we need to retire it? I would suggest we do so in major versions, like when we bump the requirement of rubocop to 1.0, and probably - do a review of all cops and decide if some are to be retired, so have all the deprecations in one release ;)

Last, but not least, Rubocop itself has a ConfigObsoletion class that informs users for removed cops, as users can have them actually in their configurations. Should we adopt the same process? Maybe we should look into how extension could extend those lists?