Pub.dev package suggestion: Consider adding a package to pub.dev with all lint rules

[rydmike]

Add and maintain all lint rules as a package on pub.dev

Currently a list of all lint rules is available as an automatically generated file here:
https://dart-lang.github.io/linter/lints/options/options.html

It would be useful if this lint rule list was also available as a package on pub.dev that is maintained and always up to date.
Developers could then use it to make their linting setup that first enables all available lint rules, and then in analysis options uses it and only turns of rules that are not desired.

Currently such setups requires first getting a copy of the all lint rules from https://dart-lang.github.io/linter/lints/options/options.html and putting it into a file, e.g. all_lint_rules.yaml that is used in the projct analysis_options.yaml file where not desired rules are turned off.

This works, but to keep up on new rules the developer has to check the page https://dart-lang.github.io/linter/lints/options/options.html for new versions regularly and update your own copy of it in the project.

A setup using this approach might look like this:

# Include and activate all lint rules, later below we disable the not used or desired ones.
# You can find a list of all lint rules to put in your all_lint_rules.yaml file here:
# https://dart-lang.github.io/linter/lints/options/options.html
include: all_lint_rules.yaml
analyzer:
  exclude:
    - "**/*.g.dart"
    - "**/*.freezed.dart"
    - "test/.test_coverage.dart"
    - "bin/cache/**"
    - "lib/generated_plugin_registrant.dart"

  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

  errors:
    # Without ignore here, we cause import of all_lint_rules to warn, because some rules conflict.
    # We explicitly enabled even conflicting rules and are fixing the conflicts in this file.
    included_file_warning: ignore
    # Treat missing required parameters as an error.
    missing_required_param: error
    # Treat missing returns as an error, not as a hint or a warning.
    missing_return: error
    # Don't assign new values to parameters of methods or functions.
    # Treat assigning new values to a parameter as a warning.
    parameter_assignments: warning
    # Allow having TODOs in the code.
    todo: ignore

# LINTER Preferences
#
# Explicitly disable only the rules we do not want.
linter:
  rules:
    # ALWAYS separate the control structure expression from its statement.
    # This sometimes makes things more unclear when one line is enough.
    # Also single line `if`s are fine as recommended in Effective Dart "DO format your code using dartfmt".
    always_put_control_body_on_new_line: false

    # ALWAYS specify @required on named parameter before other named parameters.
    # Conflicts with the convention used by flutter, which puts `Key key`
    # and `@required Widget child` last.
    always_put_required_named_parameters_first: false
  
    # Followed by more turned OFF lint rules as preferred/needed/desired and always 
    # turning off at least conflicting rules.  ​
    ...

This kind of lint setup and its benefits is described eg here and here.

While this works fine, it would be very useful if the all lint rules list could be obtained and used as a dev dep package. With versions and change log, listing changes and new rules and links to their docs. It would make maintaining the list of all used rules in projects using this type of linting setup easier.

While anybody could create and manually keep such a package in sync with the automated html doc page. I think it would be preferable if the Dart team could create it and presumably use automated package CI/CD to keep such a pub.dev package with all lint rules in sync with the currently automatically generated html doc page.

[csells]

I agree that this would be an excellent way to get the benefit of all of the lints we build as we build them. @pq what do you think? is this doable?

[asidt]

I support this 100%. What @rydmike explains is also the approach I use in my side projects and production ones, and such a maintained package would be of great help for me!

[TimWhiting]

I also use this sort of setup and would love this.

[gaetschwartz]

As a (temporary?) workaround, I created this package you can use that automatically fetches the latest rules and generates the appropriate file.

https://github.com/gaetschwartz/all_lint_rules

You can use it like so:

dev_dependencies:
  all_lint_rules_community:
    git: https://github.com/gaetschwartz/all_lint_rules

and then include all.yaml like so in your analysis_options.yaml:

include: all_lint_rules_community/all.yaml

[pq]

@pq what do you think? is this doable?

Sounds reasonable to me.

The biggest question is where to host. On dart-lang does feel appropriate. And probably not in package:lints though I guess I'm open to it.

I'd be curious to get some input from ecosystem folks...

📟 @mit-mit @natebosch @jakemac53

also fyi @srawlins

[jakemac53]

My main concern would be the conflicting lints - I have a feeling we would end up fielding a lot of issues as people tried to use this file and got conflicting lints.

If we wanted to do this then instead of having the user deal with the conflicts I would probably just make an opinionated choice where there are conflicts.

[csells]

I agree with you, @pq, that we should not drop this into package:lints but create a new package.

@jakemac53 I agree that we should provide opinions in the sample analysis_options.yaml file we show in the README so that if folks simply copy&paste (which most will), they'll have a smooth experience.

[jakemac53]

I agree with you, @pq, that we should not drop this into package:lints but create a new package.

Can we elaborate a bit more on why we would want it in a separate package? That comes with a fair bit more overhead so we should outline some clear benefits.

[csells]

I don't want to interfere with the Dart and Flutter lints we shipped in Flutter 2.5. I want folks to be able to keep using those; these would be a new choice for all the lints. If we can make that happen in the same package, that's OK with me, too.

[pq]

Can we elaborate a bit more on why we would want it in a separate package?

My biggest concern is versioning. My gut says we want to keep versioning of the recommended and core rule sets distinct from something tracking the addition of new available lints. (And I should ask, where ever this lands, would we want to bump a version every time a new lint is added to all.yaml?)

[pq]

Having said that,

That comes with a fair bit more overhead so we should outline some clear benefits.

💯

If nothing else, we'd avoid having to bikeshed a new package name 😄

[jakemac53]

My biggest concern is versioning.

Do we intend on modeling this package with breaking versions any time we add a lint to one of the published sets, or modify the behavior of a lint such that it catches more cases?

If so then yes I would probably push back pretty hard on adding an "all" set of lints to this package.

[csells]

I think the only breaking change would be removing an existing lint.

[jakemac53]

I think the only breaking change would be removing an existing lint.

Removing a lint doesn't break any builds though - its adding lints or modifying them to trigger for more cases that breaks things.

[csells]

I'd argue that's a feature in this case.