Reek config inheritance

[dimitrovv]

I've played a bit with the reek configuration and noticed it does not support config inheritance.
We've several projects, which have almost the same reek configuration with some exceptions/customization.

It'd be good to inherit the reek configuration from another reek config and override it then to DRY it etc.

It could be smth like that

• ancestor/.reek.yml

---
### Generic smell configuration
detectors:
  Attribute:
    enabled: true
    exclude: []
  BooleanParameter:
    enabled: true
    exclude: []
  ClassVariable:
    enabled: true
    exclude: []
  ControlParameter:
    enabled: true
    exclude: []
  MissingSafeMethod:
    enabled: false
### Directory specific configuration
directories:
  "app/controllers":
...

• descendant/.reek.yml

<%= IO.read('ancestors/.reek.yml') %>

detectors:
  MissingSafeMethod:
    enabled: true

---

This could be done by changing the way how the reek configuration is loaded in ConfigurationFileFinder#load_from_file

configuration = YAML.load_file(path) || {}

->

configuration = YAML.load(ERB.new(File.read(path)).result)

---

I'd like to PR this because we actively use reek and need this inheritance. What do you guys @troessner @mvz think of this?

[troessner]

Oh, a PR would be highly appreciated ;)
We already started discussing this in #1411 and decided to re-introduce multiple configuration files via an include directive. We would help you were possible - keep in mind though that there are multiple angles to this, e.g. validating included files against our schema. We also need to discuss what should happen when you have conflicting configurations. For instance, what should happen if you disable a smell in the main config but re-enable it in an included one. Right now this would just be overwritten which I think is also the way to go. Not sure though if there are more controversial cases even though I cant think of any right now ;)

[dimitrovv]

For instance, what should happen if you disable a smell in the main config but re-enable it in an included one. Right now this would just be overwritten which I think is also the way to go

Yep, that's right. It will be overridden. Ex. it could be enabled in the parent and disabled in the descendant. It will work, vise versa as well, have tested this.

keep in mind though that there are multiple angles to this, e.g. validating included files against our schema

Yes, should be fine, the schema validations will still be taken into account.

---

I'll try to PR this so you guys could review and give some advice if needed, will appreciate. It could also be smth like inherit_from feature that rubocop has, but I think a simple YAML load with binding will do the job here.

[troessner]

Sounds great, looking forward to this!

[junket]

@dimitrovv @troessner Awesome stuff. I've found RuboCop's addition of an inherit_gem directive handy too, and it was done with few LOC: rubocop/rubocop@e9764ea

In the spirit of DRY, I've found myself moving a lot of stuff into gems, so being able to reference Reek config in an included gem would be pretty great. Just a thought. Great work and thanks!

[mvz]

@junket I'd really like to see a concrete example of that, since the documentation in the rubocop PR is rather hand-wavey.

[mvz]

😱 https://github.com/glebm/i18n-tasks/blob/6216ba6e5469df89248bafd2a37f43f02707a713/lib/i18n/tasks/configuration.rb#L25