Allow pass-through of more error overrides, e.g. when they mute lint rules from the included options file but not affecting default lint rules.

[csells]

If I ran dart analyze on my local package (dartantic_ai in this case), I get the following output:

dart analyze lib/dartantic_ai.dart
Analyzing dartantic_ai.dart...         0.5s
No issues found!

However, if I run pana, I get the following int the Pass static analysis category:

## ✗ Pass static analysis (40 / 50)
### [~] 40/50 points: code has no errors, warnings, lints, or formatting issues

Found 4750 issues. Showing the first 2:

<details>
<summary>
INFO: Unnecessary use of single quotes.
</summary>

`lib/dartantic_ai.dart:6:8`

  ╷
6 │ export 'src/agent/agent.dart';
  │        ^^^^^^^^^^^^^^^^^^^^^^
  ╵

To reproduce make sure you are using the [lints_core](https://pub.dev/packages/lints) and run `dart analyze lib/dartantic_ai.dart`
</details>

<details>
<summary>
INFO: Unnecessary use of single quotes.
</summary>

`lib/dartantic_ai.dart:7:8`

  ╷
7 │ export 'src/agent/model_string_parser.dart';
  │        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ╵

To reproduce make sure you are using the [lints_core](https://pub.dev/packages/lints) and run `dart analyze lib/dartantic_ai.dart`
</details>

Obviously there aren't 4750 issues and how would one of them be "Unnecessary use of single quotes," given that it's an export statement? This is a regression.

[isoos]

pana does not take all analysis_options.yaml rule as-is, because we want to have some kind of comparable uniformity over the packages. In general we want to have only a minimum set of rules, mostly the defaults that are added when you create a new dart package.

However, recently we've updated the handling of the analysis_options.yaml, to allow more pass-through options, mostly for allowing custom formatting rules. This however affects you much more than others, since now your package will use every lint rule (at least defined in package:all_lint_rules_community), but we don't honor the exlcudes here:
https://github.com/csells/dartantic_ai/blob/main/packages/dartantic_ai/analysis_options.yaml#L17-L21

The good news is that #1512 already will allow most of these to be pass-through:
https://github.com/csells/dartantic_ai/blob/main/packages/dartantic_ai/analysis_options.yaml#L25-L39

And with that the pana HEAD now reports only 442 issues for the package. It is clearly not ideal, and we should probably do pass-through of the options in the analyzer: errors block, similarly to #1512 if we can say that they do not affect the rules that we want to otherwise enforce. I'll update the title of this issue to reflect it.

[csells]

ouch. I'm more restrictive on the Dart code I accept and pana penalizes me for it? that seems backwards. and that 150/160 points on pub.dev hurts my heart!

[sigurdm]

I'm more and more in the camp of: "use whatever ruleset the user has chosen, but chose the lints_core rules if there is no analysis options". I think it is enough if people have made a conscious choice of rules - it doesn't have to be the same as our preference.

@jonasfj @szakarias @mit-mit WDYT?

[isoos]

I think it is enough if people have made a conscious choice of rules - it doesn't have to be the same as our preference.

My worry is that this would allow to have an empty analysis_options.yaml or worse, one that ignores all errors. Maybe that is fine.

Maybe we need to provide uniform analysis for the actual dependency graph instead, e.g. if the package has a set of rules, all of its dependencies is also measured by the same rules (though it may make more sense as a local audit than a pub.dev analysis).

[sigurdm]

Yeah my thinking is, that if you really want to ignore all errors, then that is what you want.
We cannot really help everyone - people can write bad packages that get full analysis points anyways. But guiding people towards having an explicit analysis_options file seems like it brings value to the community.

[csells]

If you think of it from the other direction, why do we even allow a custom set of analysis options if we're just going to disable them when they publish? How can I arrange my project consistently if the publication process turns It off?

So I'm with @sigurdm (obviously : )

[isoos]

If you think of it from the other direction, why do we even allow a custom set of analysis options if we're just going to disable them when they publish? How can I arrange my project consistently if the publication process turns It off?

The analysis (and by proxy the code) is important for both for the producer (auther/developer) and the consumer (user who wants to use the package, and may consider multiple options for their use-case). From the producer's perspective, I agree with you. But I think it is important to also look at it form the consumer's point of view, which is much easier if the packages are measured against the same metrics.

[csells]

If you're going to grade on your own analysis options, can I have them so I can make sure my packages pass? It doesn't do me any good to have my own if you're going to ignore them.

[isoos]

If you're going to grade on your own analysis options, can I have them so I can make sure my packages pass? It doesn't do me any good to have my own if you're going to ignore them.

You can run pana locally, it should give the same result as on pub.dev. The next release of pana will have #1516 in it, which now allows a pass-through for most of your options, so your package will get 160/160.

[csells]

Thanks but it's not enough to run pana, which I do as the last step before publication. I want to have the analysis options that pana checks my project against as part of my project so I can fix issues as part of my dev process. Thanks.