Skip to content

A lean linter (for a sustainable future). #57427

Open
@pq

Description

@pq

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


Sub tasks:


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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3A lower priority bug or feature requestarea-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.contributions-welcomeContributions welcome to help resolve this (the resolution is expected to be clear from the issue)devexp-linterIssues with the analyzer's support for the linter packagetype-enhancementA request for a change that isn't a bugtype-questionA question about expected behavior or functionalitytype-taskA well-defined stand-alone task

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions