analysis_options is "everything or nothing" for generated code

[JCKodel]

Generated code (through build_runner or whatever) often have analysis issues.

Usually, on our own code, we regulate those issues through analysis_options.yaml.

Since the generated code is uneditable and we cannot control how it is generated, we often need to ignore some rules just on generated code, which is impossible.

If we use the exclude key to exclude **.g.dart, then errors do not appear anymore (example: some class that is referenced in generated files and are not imported through import 'class.dart'; just doesn't appear on VSCode problems window (you will only know about them when you try to build).

So:

1. Stop ignoring "ERRORS" just because the file is in the exclude section of analysis_options.yaml. It doesn't make sense whatsoever to ignore COMPILE errors!

2. Allow us to use a different list of rules for some path, in analysis_options.yaml, so I can ignore unused_element (or whatever) for **.g.dart, but not for my files.

3. Since part and part of infers that we're using multiple files as one, make // ignore_for_file: unused_element work on the root file (i.e.: the file that imports the .g.dart file through part 'some.g.dart';)

[bwilkerson]

1. Stop ignoring "ERRORS" just because the file is in the exclude section ...

I agree that we need to have better support for controlling the diagnostics reported for generated code.

However, the purpose of the exclude section is not to control which diagnostics are reported, it's to indicate that you don't want the file to be analyzed at all unless it's required as part of analyzing other non-excluded files.

So while I agree with the goal, I think we need a different solution.

Allow us to use a different list of rules for some path ...

It is possible to add an analysis options file in any directory, and that file will control the options used for any files in that directory structure. If the generated code is in a different directory than non-generated code, then you could have a different list of rules today.

What we don't have is support for having different rules for two libraries in the same directory.

Since part and part of infers that we're using multiple files as one ...

I don't think that solution works well with the enhanced-parts language feature, so I don't think that would be a good change to make. We haven't really looked in-depth at how ignores should work under that feature, though, so it's possible that I might be wrong.

[JCKodel]

It is possible to add an analysis options file in any directory, and that file will control the options used for any files in that directory structure. If the generated code is in a different directory than non-generated code, then you could have a different list of rules today.

For this scenario, it works, but, since almost all generators generates code on the same folder (usually a file.dart and a file.g.dart), that won't work. Luckily, all generators I use are based on source_gen, which has a configurable preamble section where I can add some // ignores. But many others use build_runner, which have no option for that, AFAIK.

So while I agree with the goal, I think we need a different solution.

Maybe a new option like

ignore_all_lint_rules_for_this_glob_but_keep_showing_compile_errors:
  - **/*.g.dart
  - **/*.mapper.dart

Just a bit shorter =P

[bwilkerson]

Yes, it's shorter. We might want something a little more flexible, though.