Remove runtime dependency on lint_roller

[bquorning]

rubocop-rspec should not need to have a runtime dependency on lint_roller. And since RuboCop v1.72.1 already has a dependency on lint_roller ~> 1.1.0, it should be safe to remove from our gemspec.

---

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]

cc @paracycle

[pirj]

No objections
I wonder, if we had it, do we use it?
I’m a tad concerned if RuboCop drops or replaces it, will it still work for us?

[bquorning]

I don't think RuboCop will drop it, then the whole plugin loading would stop working.

But I would like @koic's comment. We spoke briefly about it today at RubyKaigi.

[bquorning]

I’ll move this PR to draft while I rethink some problems with lint_roller…

[koic]

Unless something has been overlooked, declaring a runtime dependency on lint_roller in the gemspec would be a safer way to stabilize the dependency on the intermediate API layer provided by lint_roller.

Although the likelihood is low, if RuboCop were to depend on a future version such as lint_roller 2.x that introduces breaking changes, an incompatibility might arise between lint_roller 2.x (required by RuboCop) and lint_roller 1.x (required by a plugin, such as RuboCop RSpec).

By specifying the dependency in the gemspec, potential errors caused by an unexpected update to lint_roller during bundle update can be avoided. This is because both RuboCop and the plugin would remain dependent on the lint_roller 1.x API until the plugin explicitly resolves compatibility with lint_roller 2.x.

When removing the dependency on lint_roller, it is necessary to consider whether the plugin can accept the risk of version mismatch should such a situation occur.

By the way, @bquorning, I was glad to meet you at RubyKaigi 2025!

[bquorning]

I realize that currently this line prevents us from removing lint_roller as a dependency – by always loading plugin.rb, lint_roller is a direct dependency.

Although the likelihood is low, if RuboCop were to depend on a future version such as lint_roller 2.x that introduces breaking changes, an incompatibility might arise between lint_roller 2.x (required by RuboCop) and lint_roller 1.x (required by a plugin, such as RuboCop RSpec).

If the version 2 API is incompatible with the current API, I would expect lint_roller to also change what needs to be entered into our gemspec metadata. Perhaps they would use a 'default_lint_roller_v2_plugin' key? That way we could ship one gem with support for two plugin systems.

By the way, @bquorning, I was glad to meet you at RubyKaigi 2025!

Likewise 🙏🏼

[bquorning]

As a hypothetical / abstract example, what if we wanted rubocop-rspec to also be a plugin of another linter project than RuboCop, using a different way to write plugins? Should we then give rubocop-rspec another extra runtime dependency? I don’t think so.

I think if our gemspec metadata defined a path instead of a class name, rubocop would be able to load our plugin code, and rubocop-rspec would not have any knowledge (besides defining, but not loading, a Plugin class) of the plugin system.