When I run rubocop in my project everything passes.
I have turned on the precommit hook with overcommit. When trying to commit I get:
Errors on lines you didn't modify:
/Users/Pawel/code/project/Gemfile:1:1: C: Style/FileName: Use snake_case for source file names.
Why are these two results different?
The output of rubocop -V:
$ rubocop -V
0.38.0 (using Parser 2.3.0.6, running on ruby 2.2.3 x86_64-darwin14)
$ overcommit -v
overcommit 0.32.0
The first line of Gemfile that is allegedly wrong:
source 'https://rubygems.org'
.rubocop.yml:
inherit_from: .rubocop_todo.yml
Rails:
Enabled: true
AllCops:
Include:
- '**/Rakefile'
- '**/config.ru'
Exclude:
- 'db/**/*'
- 'config/**/*'
- 'vendor/**/*'
.overcommit.yml:
PreCommit:
RuboCop:
enabled: true
Looking back at overcommit release 0.32.0, their Gemfile has RuboCop locked at:
gem 'rubocop', '0.37.2'
So this was likely fixed at some point between 0.37.2 and 0.38.0, and the fix should be to update to the latest overcommit.
Having a similar issue, on rubocop 0.43.0. Running rubocop manually works fine and does not show the error, but in Neovim with Neomake which automatically runs recognized linters as rubocop, I get the warning about snake_case in the Gemfile.
I'm also seeing this on 0.48.0
$ rubocop
Inspecting 23 files
CC.................C...
Offenses:
...
Gemfile:1:1: C: Style/FileName: The name of this source file (Gemfile) should use snake_case.
source 'https://rubygems.org'
^
I was also seeing this with 0.49.1 for Capfile:
Capfile:1:1: C: The name of this source file (Capfile) should use snake_case.
# Load DSL and Setup Up Stages
^
Adding **/Capfile to the AllCops: Include: list fixed it.
This behavior is so counter-intuitive it's funny. Capfile is a file type that's hard-coded to be inspected, but in Naming/FileName we skip inspection if a file is listed in AllCops: Include, because then you have okayed its name.
So add the file name under AllCops: Include if you want to exclude it from inspection by Naming/FileName.
Just tripped over this after upgrading to 0.53.0. Thanks for the workaround @jonas054!
Most helpful comment
I'm also seeing this on 0.48.0