Support configuration file

[jpsim]

Something like a .swiftlint.yml or similar that could be used to override rule parameters or turn off certain rules globally. See #1.

[aarondaub]

What is the support for YAML like? Should we limit it to the JSON subset, or is YAML well enough supported?

[skywinder]

+1 👍
it will awesome to have .swiftlint.yml with custom rules.
as a good example of this approach is .rubocop.yml for ruby linter https://github.com/bbatsov/rubocop

[chriseidhof]

I played around a bit, and came up with a possible solution. Maybe this is too complicated, so feel free to build something simpler ;).

For every Rule, we can make a separate struct which holds the configurable values. For example, for the TodoRule, we might want to configure the words:

struct TodoRuleConfiguration {
    var words = ["TODO", "FIXME"]
}

Now, if we want to capture the fact that words is an option, we can create a struct ConfigurationOption which allows us to describe the options name (e.g. this is what people specify in the YAML) and a way to apply it to a configuration of type A. Because we don't really know what type will come in, we will try to do a cast within the apply function, and return an updated A if this succeeeds. Otherwise we return nil (which means: couldn't parse option). This should probably return a Result rather than an optional.

struct ConfigurationOption<A> {
    let name: String
    let apply: (A, Any) -> A?
}

For example, one option would be the keywords option:

let keywordsOption = ConfigurationOption<TodoRuleConfiguration>(name: "keywords", apply: { (var copy, value) in
    if let words = value as? [String] {
      copy.words = words
      return copy
    }
    return nil
})

Now, to say that a configuration (e.g. TodoRuleConfiguration) has options, we can create a protocol:

protocol Configurable {
    var options: [ConfigurationOption<Self>] { get }
}

extension TodoRuleConfiguration: Configurable {
    var options = [keywordsOption]
}

And finally, now that we have all of that in place, we can write a simple applyConfiguration function, which takes a rule, a list of (untyped) option values (this can be a YAML dict, or JSON dict, or whatever) and returns a new rule with all the options applied. Again, this might also produce errors, not sure how we should handle them (hence the TODO).

func applyConfiguration<A: Configurable>(var rule: A, optionValues: [String:Any]) -> A {
    for option in rule.options {
        if let value = optionValues[option.name] {
            if let newRule = option.apply(rule, value) {
                rule = newRule
            } else {
                // TODO: option could not be parsed
            }
        }
    }
    return rule
}

I realize this might look complicated, but I think it should be easy to work with. The nice thing about making it all explicit is that we can also generate documentation for the options, and we can easily add some more fields to the ConfigurationOption struct, (e.g. a short description of the option).

[jpsim]

It does seem a bit complicated, and maybe even overlapping with the concepts of RuleParameter/ParameterizedRule, but I think that once a draft implementation is done, some of these concerns will naturally go away just by getting to a working state.

So in other words, go for it! 😄

[bsrz]

@jpsim I'm coming in late in this conversation but has the option of passing parameters at the command line been looked into?

./swiftlint --max-characters 120

[jpsim]

not as command line arguments, no.

[bsrz]

Has it been rejected?

[jpsim]

No, it hasn't been considered. Really the mechanics for enabling command line arguments as rule parameters are very similar to doing so via a configuration file. Feel free to take a stab at implementing that if you'd like.

[bsrz]

Ok, sounds good!
Thanks for the information, I'll try to find some time to try this out.

[jpsim]

Done in #99.