Merge nested configurations rather than replacing them outright

[jpsim]

We currently just replace parent configurations with nested ones, but it'd be nicer and less confusing to users if nested configurations inherited their parents.

Current source: https://github.com/realm/SwiftLint/blob/0.10.0/Source/SwiftLintFramework/Models/Configuration.swift#L220-L225

Currently merge simply overrides the current configuration with the new configuration.
This requires that all configuration files be fully specified. In the future this should be
improved to do a more intelligent merge allowing for partial nested configurations.

See #675 for one case of such confusion.

[dgommers]

We were also facing this behaviour within our project. I would like to help by implementing this mini-feature. But before going there, I am considering an specific approach and I would like to see if this matches with other SwiftLint maintainers' vision.

Instead of implementing the placeholder merge method on the Configuration struct, I would like to propose to perform it on a lower level. This will make the implementation more scalable and responsive to any changes on content level.

More specific:

1. Parse configuration files directly into a dictionary, instead of Configuration struct, which is currently implemented inside configurationForPath method (recursively).
2. Merge-in each dictionary, not requiring any knowledge about the actual contents (improves scalability).
3. Initialise the Configuration struct based on the combined dictionary.

Thanks!

[jpsim]

I don't think that's the right way to do this. For one, merging two Configuration structs has the advantage of dealing with strongly-typed values, and to avoid parsing/interpreting the untyped YAML dictionary. For another, we already have Configuration values that we need to construct for the subsets of the files on which they apply.

[ManWithBear]

Hi, I have started to implement this feature.
Do you have any ideas how it should work?
Right now I think to separate Configuration rules in 4 categories Disabled, Configured, Custom, Default. And combine it like: child configured rules fully override parent configured/default rules with same ID. And after that combine rules together and remove all disabled by parent or child.

[jpsim]

Hi @ManWithBear , I think it'd be best to file a PR with the behavior your think is best, and we can review/adapt from there.

[marcelofabri]

Thanks @stephanecopin and @jpsim 💯

[andrewtheis]

This feature seems to have broken cases where you wish the nested config for a rule to override the settings in the parent.

[jpsim]

@andrewtheis can you be a bit more specific? Please file an issue with more details about what you want compared to what the current behavior is.