Extended RuboCop::Lts config shims for the RSpec-related Cop rules,
back to Ruby version 1.8. Part of the rubocop-lts
gem family.
Use the rules standard gives you, and then add more, to increase your code's compatibility across multiple versions of Ruby.
Only reach as far back as you need to go!
The RuboCop LTS family of gems is the distillation of 20+ years of my own Ruby expertise and source code diving, built on the shoulders of the expertise of many others; organizing that expertise into per-Ruby-version sets of configurations.
Although the situation has improved somewhat, it remains unsafe to upgrade RuboCop, or Standard, in a project that supports EOL Rubies.
I hope it helps others avoid some of the challenges I've had with library maintenance, and supporting decade-old mission-critical applications.
Avoid bike-shedding, use rubocop-lts
in every project, and
let it manage your linting complexity!
If the rubocop-lts
stack of libraries has helped you, or your organization,
please support my efforts by making a donation, or becoming a sponsor.
NOTE: You might be interested in also using rubocop-lts
which sits conceptually at a higher level than this gem.
Starting with the rubocop-lts Epoch v1 series (i.e. SemVer major versions 1_0XX) each config in rubocop-lts
has an rspec version that depends on this gem,
but if you want to use them, you must add the dependency on this gem to your gemfile/gemspec separately.
It will enable your RSpec style rules to be integrated with your Ruby style rules,
and for the entire suite of rules to target, with an explicit goal of compatibility,
whatever version of Ruby your project happens to be on!
Gem Name | Version | Downloads | Activity |
---|---|---|---|
rubocop-lts |
[![Current][πlts-cwfi]][πlts-cwf] | ||
rubocop-lts-rspec |
The rubocop-lts
family of gems has a version supporting any version of Ruby you need.
They can be used as development dependencies for libraries or applications.
rubocop-lts
rubocop-lts-rspec
standard-rubocop-lts
rubocop-ruby1_8
rubocop-ruby1_9
rubocop-ruby2_0
rubocop-ruby2_1
rubocop-ruby2_2
rubocop-ruby2_3
rubocop-ruby2_4
rubocop-ruby2_5
rubocop-ruby2_6
rubocop-ruby2_7
rubocop-ruby3_0
rubocop-ruby3_1
rubocop-ruby3_2
rubocop-ruby3_3
rubocop-ruby3_4
All releases of this gem are stable releases.
We do not release new versions for every release of rubocop
,
as this gem is part of rubocop-lts, which is tied to standard (Standard Ruby).
A typical release cycle for a gem in the rubocop-lts
family is roughly every six months,
though eventually analysis support for an old version of Ruby will become impossible,
because of limitations of RuboCop.
When that happens releases of the rubocop-lts
gem for that version of Ruby will (mostly) cease.
For now though, in Q2 2025, RuboCop can still be used with code targeting Ruby v1.8.7, and newer.
Tokens to Remember | |
---|---|
Works with MRI Ruby 3.2+ | |
Source | |
Documentation | |
Compliance | |
Expert 1:1 Support | or |
Enterprise Support | π‘Subscribe for support guarantees covering all FLOSS dependencies! π‘Tidelift is part of Sonar! π‘Tidelift pays maintainers to maintain the software you depend on! π @ Pointy Haired Boss: An enterprise support subscription is "never gonna let you down", and supports open source maintainers! |
Comrade BDFL ποΈ | |
... π |
Install the gem and add to the application's Gemfile by executing:
$ bundle add rubocop-lts-rspec
If bundler is not being used to manage dependencies, install the gem by executing:
$ gem install rubocop-lts-rspec
After adding both this gem and rubocop-lts
to your Gemfile or gemspec,
utilize a config provided by rubocop-lts
.
The configs that end in *_rspec.yml
will pull in all the config from this gem,
specifically for the version of Ruby indicated by the version of rubocop-lts
you are on.
inherit_gem:
rubocop-lts: config/ruby_rspec.yml
inherit_gem:
rubocop-lts: config/rubygem_rspec.yml
inherit_gem:
rubocop-lts: config/rails_rspec.yml
After adding both this gem and rubocop-ruby#_#
to your Gemfile or gemspec,
utilize a config provided by rubocop-ruby#_#
.
The configs that end in *_rspec.yml
will pull in all the config from this gem,
specifically for the version of Ruby indicated by the version of rubocop-ruby#_#
you are on.
For this example we will use the rubocop-ruby3_2
gem.
Replace only the gem name key if you are using a different one:
inherit_gem:
rubocop-ruby3_2: rubocop-lts/ruby_rspec.yml
inherit_gem:
rubocop-ruby3_2: rubocop-lts/rubygem_rspec.yml
inherit_gem:
rubocop-ruby3_2: rubocop-lts/rails_rspec.yml
If you are using this gem standalone, add to the top of your project's .rubocop.yml
configuration file:
inherit_gem:
# Replace {RUBY_MAJOR_VERSION} with the minimum major version of ruby you want to target.
# Replace {RUBY_MINOR_VERSION} with the minimum minor version of ruby you want to target.
rubocop-lts-rspec: config/ruby-{RUBY_MAJOR_VERSION}-{RUBY_MINOR_VERSION}.yml
What will this do for me?
Among other potential settings specific to your chosen minimum version of ruby, the above effectively results in the following config (& more):
inherit_mode:
merge:
- Exclude
- Include
require:
- rubocop-lts-rspec
- rubocop-rspec-extra
- rubocop-env
- rubocop-rspec
inherit_gem:
rubocop-env: config/default.yml
rubocop-rspec-extra: config/default.yml
Don't worry about it, it will be configured for you.
See CONTRIBUTING.md.
See SECURITY.md.
If you need some ideas of where to help, you could work on adding more code coverage, or if it is already π― (see below) check TODOs (see below), or check issues, or PRs, or use the gem and think about how it could be better.
We so if you make changes, remember to update it.
See CONTRIBUTING.md for more detailed instructions.
Everyone interacting in this project's codebases, issue trackers,
chat rooms and mailing lists is expected to follow the .
Made with contributors-img.
Also see GitLab Contributors: https://gitlab.com/rubocop-lts/rubocop-lts-rspec/-/graphs/main
This Library adheres to .
Violations of this scheme should be reported as bugs.
Specifically, if a minor or patch version is released that breaks backward compatibility,
a new version should be immediately released that restores compatibility.
Breaking changes to the public API will only be introduced with new major versions.
Yes. But I'm obligated to include notes...
SemVer should, but doesn't explicitly, say that dropping support for specific Platforms is a breaking change to an API. It is obvious to many, but not all, and since the spec is silent, the bike shedding is endless.
dropping support for a platform is both obviously and objectively a breaking change
- Jordan Harband (@ljharb) in SemVer issue 716
To get a better understanding of how SemVer is intended to work over a project's lifetime, read this article from the creator of SemVer:
As a result of this policy, and the interpretive lens used by the maintainer, you can (and should) specify a dependency on these libraries using the Pessimistic Version Constraint with two digits of precision.
For example:
Made with contributors-img.
The gem is available as open source under the terms of
the MIT License .
See LICENSE.txt for the official Copyright Notice.
Project Logos (rubocop-lts-rspec)
Organization Logo (rubocop-lts)
- Author: Yusuf Evli
- Source: Unsplash
- License: Unsplash License
Copyright (c) 2023 - 2025 Peter H. Boling,
RailsBling.com
You made it to the bottom of the page, so perhaps you'll indulge me for another 20 seconds. I maintain many dozens of gems, including this one, because I want Ruby to be a great place for people to solve problems, big and small. Please consider supporting my efforts via the giant yellow link below, or one of the others at the head of this README.