Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support rubocop-performance 1.17.x as well #4

Closed
BrianHawley opened this issue May 9, 2023 · 4 comments
Closed

Support rubocop-performance 1.17.x as well #4

BrianHawley opened this issue May 9, 2023 · 4 comments

Comments

@BrianHawley
Copy link

The spec.add_dependency "rubocop-performance", "~> 1.16.0" restriction causes bundler to choose standard gem versions less than 1.0, if rubocop-performance was already in the Gemfile. Can "~> 1.16" be used instead?

Don't know why dependabot didn't catch this one.

@searls
Copy link
Contributor

searls commented May 9, 2023

We intentionally track the minor version of rubocop-performance because each minor release brings significant enough changes so as to break the configuration from time to time.

We release standard on a monthly release cadence which will include the latest rubocop-performance update as well.

If you're finding that Bundler is resolving to a <1.0.0 release of Standard, is it by chance 0.0.36.1? If so, then the root cause may be what had previously been an unbounded dependency on RuboCop by the standard gem.

If not, if you could provide a reproducing Gemfile + lockfile, that'd be helpful in figuring out what else is going on

@BrianHawley
Copy link
Author

BrianHawley commented May 23, 2023

Yup, that was the version bundler picked.

My use case is updating codeclimate's rubocop engine, beta channel, to the latest version of the rubocop gems listed, when those gems are updated.

Recently, someone decided to add references to the standard gem to the rubocop engine, so that people who run standard through rubocop can use the rubocop engine to do so (see codeclimate/codeclimate-rubocop#351 for details). However, since then, standard's gems have been limiting the versions of rubocop's gems. For instance:

  • rubocop is 1.51.0 but standard requires "~> 1.50.2".
  • rubocop-performance is 1.18.0 but standard-performance requires "~> 1.16.0".

It would be nice if standard's gems could either be more flexible in their integration, or keep up with the release cadence. I know, it may be unreasonable to ask, especially since standard has their own codeclimate engine.

@BrianHawley
Copy link
Author

BrianHawley commented May 23, 2023

For context, I think that standardrb/standard#439 may be related to why they added standard to the codeclimate rubocop engine. The codeclimate standard engine hasn't been updated in a while, and (as of that issue) doesn't seem to support loading standard from rubocop, so as to support the rubocop addons that standard doesn't support yet.

@searls
Copy link
Contributor

searls commented May 24, 2023

Standard releases upstream from RuboCop on a monthly cadence and I don't think we're going to change that, because one of the benefits of using Standard is that we take care to consider and it's time-consuming to cross-reference changelogs, documentation changes, and the (typical) flurry of post-release fixes to new cops. Additionally, because config-file breaking changes are often included in minor releases, we won't further loosen the version specifier either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants