Remove RSpecRails/InferredSpecType

[bfad]

At the time this cop was added, it was noted that this was legacy behavior left as the default for people migrating to RSpec 3. Now RSpec 7.1.0 has removed this default to make it clear that this is deprecated / legacy behavior, let's delete this cop.

Replace this text with a summary of the changes in your PR. The more detailed you are, the better.

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[bquorning]

Probably we'll need to add a config/obsoletion.yml file too.

[pirj]

The setting’s default has just been changed in a rspec-rails version.
There are, and in the next years there will be plenty of projects with rails_helper that has this option turned on.

And the option is still there to opt-in.

The cop is marked as unsafe, meaning it doesn’t raise offences normally.

Basing on all this, I suggest changing the documentation to reflect the above, keep the cop, keep the cop enabled.

[bfad]

Here's the problem as I see it: the templates for generating specs (from scaffolding or just generating individual controllers, models, etc.) have the type: specifications, and they have had them for years. Keeping this cop enabled by default makes it seem like the best practice is to remove those type annotations from the spec. I know this because I have been doing it on a recent project. However, that isn't the recommended best practice (and hasn't been since before the cop's creation).

So if we keep the cop enabled by default, the worst thing that will happen is that people will get a warning and remove the type specifications believing that Rubocop's defaults are recommending best practices. This will be for both older and brand new projects since this cop doesn't check to see if config.infer_spec_type_from_file_location is set.

If we remove the cop, the worst thing that will happen is that people who have config.infer_spec_type_from_file_location turned on won't get warned if they add a spec with a type specification.

Not being warned that a new spec is following best practices and is future-proofed against a deprecated option doesn't seem as bad as actively recommending that people use a long-deprecated feature.

[pirj]

Fair enough.
A recent rspec-rails issue to support this rspec/rspec-rails#2815 (comment)

[pirj]

No objections. We’ll need a major version bump to release?

[bquorning]

The question is, when do we want to do a major release?

(Also, I read about BreakVer recently; maybe that would be better to follow than SemVer?)

[bquorning]

@bfad

Please run rake generate_cops_documentation and add docs/ to the commit.

[pirj]

@bquorning Ha! I haven't heard about BreakVer, and agree with its message. However, I'm slightly concerned of CI breakages - those people who explicitly enabled this cop in their configs (by default it's still pending) will have to remove a couple lines from their .rubocop.yml (an effort usually associated with a major version update). Not a big effort, low chance of making someone's CI red (for more than the gem update PR itself), unlikely reputational changes.
My worry here is the incompatibility of BreakVer and SemVer. I'd be totally happy if everyone in our ecosystem moved to BreakVer overnight, so there's no surprise. But this is impossible, not to say for older versions.

On the other hand, we can do a major release.

Along the way, there are quite some pending cops waiting to be enabled here, and also in rubocop-capybara and rubocop-factory_bot. I haven't seen major complaints from NewCops: enable early adopters. It's high time to release all that!

[pirj]

Fixed master CI config/docs failure, rebased.

[bfad]

Fixed master CI config/docs failure, rebased.

Thanks for updating this.