Linter: What lints operate on file-by-file (i.e., would not need package graph/analysis)

[matanlurey]

When adding command line lints in large applications/build systems, file-by-file linting is greatly preferred due to nice scaling and parallelization. Some of the lints though, seem to need resolved ASTs and analysis 😢

Could we have a mode that only allows running file-by-file lints, i.e. (strawman):

$ linter --no-resolution --rules=...

If rules are added that require resolution, linter could throw.

[pq]

👍 We've talked about this a little. I think it's a great idea. A handful of lints work purely on syntactic information so should absolutely be runnable without resolution. It'd be great to be able to use those in contexts where full resolution isn't possible.

cc @bwilkerson

[matanlurey]

Nice!

[bwilkerson]

@pq It might be useful to the discussion to make a list of the lints that could run in this environment (or at least count how many will and how many won't) so that we know whether it's worth the implementation effort.

[pq]

Not a complete list but a start:

• avoid_empty_else
• avoid_init_to_null
• avoid_return_types_on_setters
• camel_case_types
• control_flow_in_finally
• empty_constructor_bodies
• empty_statements
• library_names
• library_prefixes
• throw_in_finally
• super_goes_last
• valid_regexps

Plenty enough there to pursue it further.

I'm open to ideas on how we should identify these rules (annotation? property?) Ideally this will get folded into rule documentation as well.

[zoechi]

how we should identify these rules

Perhaps some kind of group or tag like also discussed in #288

[pq]

A simple thing we might do is add a property to LintRule that can be queried to create groups dynamically.

For example, something like requiresResolution:

Iterable<LintRule> perFileLints = allRules.where((LintRule r) => !r.requiresResolution);

Then it's just up to lint authors to identify lints appropriately.

cc @bwilkerson

[bwilkerson]

I expect that we will need to maintain this list, not depend on authors.

If a group would solve the problem I'd rather we spent our time supporting groups rather than add a different mechanism for it.

[matanlurey]

I think this is being solved by @danrubel's new features for now.