A lean linter (for a sustainable future).

[pq]

PROPOSAL: remove the linter CLI and reduce the linter package to a kernel of lint rules, tests and testing support.

---

Sub tasks:

• Remove bin/linter
• Update README docs to explain how to run lints in the new world (Label names in the same scope must be unique. #393)

---

Background: the linter depends on analyzer package internals and so is vulnerable to prolonged build breakages between stable analyzer releases. At the heart of these dependencies is support for the linter command-line tool. This tool was built at the project's outset, when the dartanalyzer did not support running lints (it does now) and has continued to evolve to support linting in particular.

It duplicates a lot of logic in the dartanalyzer CLI. Notably it duplicates all the work done by the analyzer to setup analysis (e.g., creating resolvers, setting package roots, configuring SDK locations, etc). While effort has been made to reduce this duplication and push this functionality into the analyzer kernel, it has been the source of ongoing maintenance.

The linter CLI also provides some refinements to the analyzer CLI with an eye towards supporting linting in particular. The way it displays errors, for example, is a bit more verbose, and it provides a useful --stats option to collect and display lint occurrence counts.

PROS

By removing the CLI bits from the linter, it notably

• will becomes less vulnerable to breakage from analyzer API changes,
• can have a greatly reduced dependency set making it less vulnerable to package versioning issues, and
• will be easier for contributors to reason about (and ideally contribute to)

CONS

On the downside:

• we lose some CLI user-friendliness.

Because I feel so strongly about getting the build GREEN again (sustainably) I'd like to push hard on removing the CLI. When finished, this would get us a linter that contains:

• lint rules, rule documentation and tests, with supporting
• test and doc utilities

(and would IMO be a good candidate for a 1.0.0.)

In cases where CLI niceties are missed, I propose we upstream them to the dartanalyzer CLI proper.

While I'm confident that this is the right thing to do, I realize that this change may not be popular with everyone, notably folks who have grown to depend on command-line refinements. If these folks are many (and vocal), I'd be happy to put some effort into upstreaming.

CC'ing a handful of contributors and community members but needless to say the conversation is open to all. Please chime in.

@alexeieleusis @bwilkerson @matanlurey @ochafik @dikmax @guillermooo @kevmoo @srawlins @yyoon @filiph @a14n @zoechi

Thanks in advance for any thoughts!

[dikmax]

I think separate CLI can be removed. dartanalyzer CLI is enough for most tasks.

[kevmoo]

+1. Fewer things. Simpler things. Better things.

…

On Thu, Feb 2, 2017 at 6:22 AM, Maxim Dikun ***@***.***> wrote: I think separate CLI can be removed. dartanalyzer CLI is enough for most tasks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#57427>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCij2Fri4PDqgyw-g7yBRi91-L_Gcnks5rYeadgaJpZM4L1Joq> .

[alexeieleusis]

I only use the linter CLI for testing, so the test utilities mentioned above should be a good replacement. Though often the last test I perform is run a rule against SDK and Flutter codebases, how hard will be to perform that?

Thank you!