Meta linter rules

[Sfshaza]

The list of linter rules is overwhelmingly long. How about creating two meta rules:

• "Strict Dart" which follows the styles and conventions to the letter
• "Loose Dart" which includes only the most critical rules. I'd like to have this set of rules added to DartPad.

@kevmoo @kwalrath @lukechurch

[matanlurey]

+1. It would be nice to have "Loose Dart" more or less match only Dart style guide.

[pq]

👍

At first blush, I see a couple of sub-tasks:

• Agree on what rules belong in various groupings (e.g., "strict" vs. "loose" vs. "pedantic" vs. "fly-by-night")
• Agree on how these groupings should be used. In particular are the groupings
  1. first-class in the sense that they can be referred to by name in an .analysis_options file, or more simply just
  2. captured in exemplar files hosted on our io page (such as the one with all rules here)

[kwalrath]

"Strict" vs. "loose" seems hard to define. Maybe we should be explicit about whether the rules are in Effective Dart and, if so, whether they're DO/DON'T or just PREFER/AVOID/CONSIDER. Here's a first cut (cc @munificent):

• effective-dart-dos-and-donts
• effective-dart-all (an alternative: effective-dart-other, but that's less clear)
• common-errors (this would cover unclosed sinks, e.g.)
• pub-rules
• (any other groups? project-specific ones, like flutter? a way to define project-specific rules? a way to turn off a specific error within a group?)

[bwilkerson]

We've talked many times about supporting some kind of user-defined lint group mechanism, and I think it makes a lot of sense. My personal preference would be to support an arbitrary number of groups rather than define a fixed number of hard coded groups, but that would be more work, so it probably won't happen.

One problem you'll run into (by not creating user-definable groups) is the issue of backward compatibility. If you define a "common-errors" group, and then someone writes a new lint that catches a common error so you add it to the group, that can be a breaking change that blocks roles into g3. You basically need to accept responsibility for fixing g3 breakage before adding new lints to any of the groups.

[kwalrath]

@bwilkerson if line-item vetoes are possible, then fixing breakages should be easier.

[zoechi]

Maybe version numbers for groups can help like with dependencies, then people can define if they want to explicitly allow new versions or use an open range to allow new rules automatically.

[tenhobi]

Is there any list which maps Effective Dart rules already?

[pq]

@tenhobi: not yet. Relatedly, #57741 introduces an evolving set of rules used internally at Google but Effective Dart would make a great general jumping off point. Feel free to open an issue or submit a PR.

Thanks!

[bwilkerson]

I'll just note that Effective Dart is often updated when the language changes, so someone would need to be able to commit to maintaining this lint set.

[alexeieleusis]

There are quite a few rules that are implemented after Effective Dart, I think most of them have names that start with avoid_ and prefer_, unfortunately that list might not be exhaustive, in that they don't cover all of Effective Dart and there might be rules verifying it and not following the name pattern. Also, these rules were implemented with Dart 1 in mind.

[bernaferrari]

I think this can be closed now that Dart has core/recommended lints and Flutter has its own linter (based on recommended).

[pq]

I agree, thanks. I don't love our existing groups (style, error, pub, ...) and think those could use some shoring up but if we want to continue that conversation, let's start new targeted issues.

Cheers!