We've avoided doing that in the past (and in fact a previous proposal for this caused us to update our lint set descriptions here: https://github.com/dart-lang/lints?tab=readme-ov-file#lint-sets).

The subjectivity increases quite a bit with strict lint sets, and something we ship often gets interpreted as the canonical version of something. Our current strategy is to publicize community lint sets (ala https://pub.dev/packages?q=topic%3Alints) - things built on top of the core, recommended, and flutter sets.

We're happy to hear other thoughts though - either re-deciding against shipping strict sets, or, better publicizing 1-3 of the more highly used, well-thought out sets.

Well that’s great and I use all_lint_rules_community myself (as I mentioned) except that @mit-mit doesn’t allow any submissions to the flutter org on GitHub to use anything that isn’t created by the Flutter team itself. So now flutter_lints is the required set and it’s inadequate (imo) for production quality code.

Personally, I use the all_lint_rules_community package for this ...

Hmm, generally, turning all the lints on is somewhat concerning. Several of the lints conflict - have opposite recommendations. Some are less well thought out, have less-than-complete implementations, or haven't aged well with the language.

So now flutter_lints is the required set and it’s inadequate (imo) for production quality code.

I am curious - which additional lints do you get value out of? Where do you see the gap between package:core+recommended+flutter_lints and production quality code?

Personally, I use the all_lint_rules_community package for this ...

Hmm, generally, turning all the lints on is somewhat concerning. Several of the lints conflict - have opposite recommendations. Some are less well thought out, have less-than-complete implementations, or haven't aged well with the language.

Of course. I turn them all on and then eliminate the conflicts via a custom analysis_options.yaml. Ideally this would be part of a flutter_lints_strict package out of the box.

So now flutter_lints is the required set and it’s inadequate (imo) for production quality code.

I am curious - which additional lints do you get value out of? Where do you see the gap between package:core+recommended+flutter_lints and production quality code?

“There are so many things that flutter_lints doesn't flag, like dynamic type usage, the lack of docs on public APIs for packages, unawaited async calls, etc.”