Unable to use CLI --list option

[pboling]

I am using the rubocop-gradual shim, so it runs instead of the standard rubocop command normally.

When I run:

NO_GRADUAL=1 bundle exec rubocop -a --list

it only prints the list of files that would be processed.

If I instead run:

bundle exec rubocop -a --list

It runs rubocop gradual ignoring the --list option entirely.

Is this intentional?

[pboling]

I'm trying to understand why my Gemfile is linted when I run standard RuboCop, but not when I run RuboCop gradual.

In fact when I use NO_GRADUAL=1 I see:

Inspecting 436 files

But when I run rubocop-gradual I see:

Inspecting 81 file(s) for autocorrection...
.................................................................................
Fixed 0 file(s).
....................................................................................................................................................................................................................................................................................................................................................................................................................................................
Found 355 files with 13150 issue(s).

Adding the 81 files found for autocorrection to the 355 files with issues it adds up to the expected 436 that standard RuboCop processes...

Perhaps that makes sense... but if I create offenses in my Gemfile RuboCop can find and fix them, but Rubocop Gradual can't. I'm stumped. RuboCop reports 66 violations in my Gemfile right now that it can't auto-correct, and the rubocop_gradual.lock doesn't have any entries for my Gemfile at all, so I am sure it is not being processed.

[pboling]

I'm guessing that this is relevant somehow (and also not entirely fixed): https://github.com/rubocop/rubocop/issues/5251

[skryukov]

Hey, sorry for the late response! I made rubocop-gradual -a to run autocorrection only for all new and changed files (according to the lock file, so it might contain old fully-linted files), this makes sense for my application – fixing files that I touched in a current PR. So, my guess is Gemfile wasn't updated when you ran the command 😅

Regarding --lint – it seems to be useful to implement it in rubocop-gradual 🤔

[pboling]

It's not --lint, but --list. :)

Also, the issue isn't related to file changes. The huge difference between running vanilla rubocop and rubocop_gradual is with zero file changes in the app at all, and a prior clean run (force_update if needed) of rubocop_gradual.

Simply from changing the command I run from rubocop to rubocop_gradual, the files processed, and the rules used during that processing, are totally different.

Also, a separate issue recently started happening. The shim no longer works at all, and I've had to switch to using the rubocop_gradual rake task exclusively.

[skryukov]

Simply from changing the command I run from rubocop to rubocop_gradual, the files processed, and the rules used during that processing, are totally different.

Yup, rubocop-gradual changes -a and -A behavior in require mode, that's kinda by design 😅

The change in rules is strange, but I didn't find anything related to that yet 😫

[pboling]

Oh I forgot to mention the other aspect of this, which is that the total number of files scanned is a huge hint as to the problem here.

Where vanilla rubocop says

Inspecting 436 files

rubocop gradual has this at the end of the run:

Found 355 files with 13150 issue(s).

This shouldn't have anything to do with the state of the file's changes.

Additionally, specifically regarding the Gemfile, it is not listed in my rubocop_gradual.lock at all, while vanilla rubocop finds plenty of violations.

[pboling]

Yup, rubocop-gradual changes -a and -A behavior in require mode, that's kinda by design 😅

But it should only change which files are modified by RuboCop gradual, not which files are "found", right?

It has to be able to, at minimum, find every file that RuboCop vanilla can find, so that it can generate a hash of the file to track in the .lock. I guess that's my core issue. The .lock has nearly 100 fewer files in it than vanilla rubocop is evaluating.

[pboling]

@skryukov The number of files inspected is still changing wildly in unexpected ways. I'll update this with --debug info as well.