Include/Exclude Globbing with '**' Should Match Files In Base Directory

[jfelchner]

The way that ** works in unix and Ruby itself is typically that it means "match zero or more subdirectories". Unfortunately the way Rubocop handles it, it matches "one or more subdirectories".

This means that you have to have this:

Exclude:
  - 'Gemfile'
  - '**/Gemfile'
  - 'config/unicorn.rb'
  - '**/config/unicorn.rb'
  - 'db/schema.rb'
  - '**/db/schema.rb'
  - 'config/deploy.rb'
  - '**/config/deploy.rb'
  - 'config/initializers/*'
  - '**/config/initializers/*'
  - 'db/migrate/*'
  - '**/db/migrate/*'

Instead of this:

Exclude:
  - '**/Gemfile'
  - '**/config/unicorn.rb'
  - '**/db/schema.rb'
  - '**/config/deploy.rb'
  - '**/config/initializers/*'
  - '**/db/migrate/*'

In fact, you can check that this is the case by opening up an IRB session in your current project base dir and run this:

require 'pathname'
Pathname.glob(ENV['PWD'] + '/**/.rubocop.yml')

And you'll see that it does in fact return the file in the base of your project.

[jfelchner]

I just noticed that you all are reinventing the wheel on a lot of the path stuff, personally I would look at the Pathname builtin library in Ruby. It does all of that stuff for you. I think it could help simplify the codebase quite a bit.

[bbatsov]

Ouch, it seems we made a serious mistake. For some reason I thought we were actually using Pathname for this. :-) @jonas054 would you have a look this?

[jonas054]

Absolutely. Thanks for the pointer, @jfelchner!

[jonas054]

It's a problem that we can't use '**/config/unicorn.rb' to match config/unicorn.rb. We have, however, added a special case for bare filenames so that 'Gemfile' matches Gemfile and dir/Gemfile.

With the File.fnmatch matching that we use, 'vendor/**' (which we have in default.yml) matches for example vendor/dir/file.rb. With Pathname.glob matching, we'd have to change it to 'vendor/**/*'.

The question is, do we just switch to Pathname.glob matching, breaking backwards compatibility, or do we keep old functionality alongside the new and issue deprecation warnings?

[bbatsov]

I'd suggest the deprecation notice option. At least for a couple of versions we have to warn users that the config format has changed.

[jonas054]

@jfelchner Could you explain in more detail what you meant when you said that we're reinventing the wheel? Because I don't quite see it. Thanks!

[jfelchner]

@jonas054 thanks so much for jumping on this. The response was more than I expected. 😄 I'll try to do some code refactoring in a PR to show you what I'm referring to, but no promises on timeframe. I'm currently releasing a large refactoring of ruby-progressbar as well as a new version of chamber.