Feature Request: Global Error Severity Configuration in analysis_options.yaml

[Artur-Wisniewski]

Request

Add support for globally configuring the error severity level of custom lint rules through the analysis_options.yaml file. This feature would allow users to customize the severity of lint rules without modifying the original lint code or creating a fork.

Current Behavior

Currently, error severity can only be set in two ways (correct me if I am wrong):
When creating a LintCode instance within the lint rule implementation:

  LintCode(
     name: 'example',
     problemMessage: '',
     errorSeverity: ErrorSeverity.WARNING
   )

Through custom rule configurations in analysis_options.yaml:

  custom_lint:
     rules:
       - example:
          error_severity: info

Proposed Behavior

Add a new configuration option in analysis_options.yaml that works similar to the standard Dart analyzer's errors section:

custom_lint:
  errors:
    example: info

This would override the default error severity defined in the LintCode class for the rule.

Benefits

• Consistent with Dart's native analyzer configuration pattern
• Allows users to adjust error severity without modifying lint rule implementations
• Facilitates the gradual adoption of custom lint in complex projects
• Avoids the need to fork third-party lint packages just to change severity levels

My Use Case

I'm introducing custom_lint in a complex client project spread across multiple repositories. Adding custom lints with default ErrorSeverity.WARNING or ErrorSeverity.ERROR would impede development by suddenly introducing many warnings or errors.
I want to introduce these lints gradually:

• Initially set all lints to info severity level so they don't block the workflow
• Progressively raise severity to warning as the team addresses issues
  Since some lint rules are from third-party packages, I can't easily modify their source code to adjust the default severity. Without this feature, I would need to fork these packages, which is maintenance overhead I'd prefer to avoid.

Implementation Details

• The errorSeverity in the LintCode class would remain as a fallback value
• A new error configuration parser would check the custom_lint.errors section in analysis_options.yaml
• If a rule name is found in this section, its configured severity would take precedence over the default

Examples

analyzer:
  plugins:
    - custom_lint
  
custom_lint:
  rules:
    - example: true
  errors:
    example: info

[rrousselGit]

Fair.
Although I probably wouldn't be implementing it before a while. If you care about it, feel free to make a Pr :)

[Artur-Wisniewski]

Hey @rrousselGit!
I've been working on it!

[Artur-Wisniewski]

#326 Is ready for code review!