Linter: Allow lints to accept configurations

[a14n]

It would be useful and nice to be able to customize some lints with parameter/configuration.

For instance:

linter:
  rules:
    - file_headers:
        pattern: '// Copyright 2015 The Chromium Authors. All rights reserved.\n// Use of this source code isgoverned by a BSD-style license that can be\n// found in the LICENSE file.'
    - prefer_const_declarations:
        local_variables: false

[a14n]

@bwilkerson @pq wdyt ?

[bwilkerson]

Honestly, I have mixed feelings. On the one hand, this can be really useful and allow a much richer UX. But it's easy to abuse, and to end up with rules that are difficult to configure.

I worked on a similar product at a previous company, and we made the mistake of adding configuration support. We didn't have outside contributions, so we had no one to blame but ourselves, but we ended up with a product that users couldn't use until they had spent multiple hours going through the list of lints to decide whether they wanted to use the lint and if so how to configure it. The task was so daunting that many of our customers never realized the full potential value of the product.

So, yeah, it would be great to be able to specify the file header to a lint so that the quick fix could insert it when it's missing. On the other hand, I'm not convinced that it isn't better, for something like "include local variables in the lint" to just make them two separate lints and allow users to enable the functionality they want by choosing the lints they enable (something they have to do anyway).

[pq]

I always thought we'd do this (see for example this old tracking issue: https://github.com/dart-lang/linter/issues/7) but as time has gone on I'm not as keen (for the reasons that Brian cites).

Very open to reconsidering though!

[a14n]

I agree configuration should be an exception. And for a file_header lint I pointed above configuration is definitively mandatory.

[jibiel]

@bwilkerson

But it's easy to abuse, and to end up with rules that are difficult to configure.

So the way to go as I see it is to introduce just a few super basic options to a linter rule which will not allow overconfiguring by design.

A good example is the Ruby linter which introduces a few basic options for each rule: Exclude, Enabled and EnforcedStyle, and maybe 1 or 2 specific (but still basic) options depending on the rule.

Here's how it looks:

Layout/AccessModifierIndentation:
  EnforcedStyle: outdent
  IndentationWidth: 0

Layout/LineLength:
  Exclude:
    - config/**/*
  Max: 80

Lint/EmptyBlock:
  Exclude:
    - spec/factories/**/*

Style/Lambda:
  EnforcedStyle: literal