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: #57153) 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

[pq]

FWIW, when trying to enable implementation_imports in analyzer I found myself really missing this. What I'd like is to be able to say _fe_analyzer is privileged (or friends or similar) since really src imports in this case are expected.

It'd be interesting to explore places that (judicious) configuration would really open up and weigh them against the downsides of the added complexity.

Input welcome!

[bwilkerson]

Is the problem that implementation_imports needs to be configurable because sometimes users validly need to reach into the src directory, or is the problem that _fe_analyzer_shared (and a few other packages in the SDK) isn't following the established conventions, and hence a lint to enforce that convention can't be used? Personally, I think it's the latter and that making the lint configurable would be bad for most of our users.

[pq]

Ah. Excellent point. If _fe_analyzer_shared were structured more for code sharing this would be a non-issue.

/fyi @stereotype441 @johnniwinther

[bwilkerson]

Yes, but it's structured the way it is because we're explicitly not making any guarantees about the API that it provides. Packages outside the SDK should never depend on it or import it.

[pq]

Understood. But isn't that what the _ is for?

In any event, probably more fuss than it's worth to get around a handful of //ignores...