Don't lint generated code

[alan-knight]

I see too many issues with the linter complaining about Intl generated code. The people seeing the problems can't really do anything about it, and in some cases it's a lot of work just to satisfy the linter. For example, it complains about the library names in generated message files, which it wants to follow a convention including their whole directory structure. Since the generator doesn't even know the directory structure this is painful. Fortunately I think I can just remove it entirely, but in general I'd rather these files could be skipped.

[bwilkerson]

Is there a way for the linter to know that these are generated files? It seems like it would be best if we didn't do any unnecessary analysis of generated files (including generating errors and warnings).

[alan-knight]

Probably not in this case, as it long predates source_gen and such. Is there a way I could tell the linter they're generated. There is a big "DO NOT EDIT. This is generated", etc. at the top. I'd be happy to add something more machine-intelligible.

[zoechi]

.analysis_options allows to exclude files #139

analyzer:
  exclude: 
    - '**/*_generated.dart'

No idea of the for of the patter is correct.

[bwilkerson]

The .analysis_options file is probably the best way. I'd like to avoid having to open and read files in order to determine whether we need to analyze them. Does the analysis options file solve the problem?

[alan-knight]

The issue with the .analysis_options is that each user has to do it. As the author of a library that generates code I can't do anything except put it in a README that no one reads.

[bwilkerson]

Yep. But the problem with using something embedded in the file is that it hurt the analyzer's performance. I don't know that there's a good solution. At least if you could generate all of these files into the same directory that every other generator uses then users would only have to add one "exclude" entry (or we could make it part of the package structure convention).

[zoechi]

I wouldn't mind configuring that in .analysis_options

[alan-knight]

Presumably opening a file and then knowing that you can ignore the rest of its contents is actually a performance improvement over reading and analyzing the whole file.

[bwilkerson]

But not over not reading the file.

[alan-knight]

But imposing the burden on the user of maintaining a bunch of entries there.

Does analysis options include excluding files for some purposes but not others? In this case users probably don't want to be told about style issues in code they don't control. But they also don't want calls into the generated code to be shown as errors, which I presume is what would happen if the analyzer just ignored those files completely.

[donny-dont]

Having done codegen I personally think the library should generate code that passes everything but the flutter rules. Those are just a bit too extreme for my liking.

That being said I would be okay if there was a file naming convention for generated files that implied they were generated like foo.g.dart.

[zoechi]

I also don't know what effect excluding in .analysis_options has. Does it just not report warning or does in skip analysing them entirely. I would still want auto-completion.

[bwilkerson]

... a file naming convention ...

I would also be fine with a file naming convention.

I also don't know what effect excluding in .analysis_options has.

It effectively says "treat this file as if it were not in this directory at all", which means that it will only be analyzed if it is referenced by some other file that is being analyzed, and only to the extent that is necessary to fully analyze the files that are not excluded. It won't generate error or warnings, and it might not do other pieces of analysis that are not required (such as evaluating constant expressions).

[zoechi]

I t effectively says "treat this file as ...

sgtm

[donny-dont]

@kevmoo source_gen uses a .g.dart right?

[kevmoo]

@donny-dont Yes, but it's not an approved convention.

I'd rather we standardize on a code comment at the top of a file to flag this

[donny-dont]

Code comment would also be okay with me. Thanks @kevmoo I figured you should probably be around for this conversation.

[bwilkerson]

@kevmoo

I'd rather we standardize on a code comment at the top of a file to flag this.

Why? It's much faster to look at the name of the file than it is to read the content of the file.

[zoechi]

I also think a file name conversation would be better. It works with all tools not only with the analyzer.

[TobiasBales]

Did anything happen after this point?

[zoechi]

The build package added support for adding headers to generated code
That allows to add // ignore_for_file: linter_rule to generated files
That solves it for me

[TobiasBales]

That sounds great, do you have any pointers on how to add that?
Because googling quickly I didn't find anything

[zoechi]

https://github.com/dart-lang/source_gen/blob/54967583163f43484838c64b59f9b8b16b809e68/CHANGELOG.md#072

Information about that seems sparse

[zoechi]

Exclude doesn't work for me
See also #25551, #29430

[westracer]

Can we get a solution for this, please? It's been 4 and a half years (!). The "exclude" option still doesn't work. My linter settings are pretty strict. I'm getting errors (not even warnings) because of someone else's code generator problems and I can't ignore them. This is very frustrating.

Getting this to work would be nice:

  exclude:
    - "**/*.g.dart"

[zoechi]

Try "dart analyze" instead of "dartanalyzer". Worked for me for the same issue (in beta channel, not sure this is available in stable already)

[5Gears0Chill]

This worked for me

in anaylsis_options.yaml

analyzer:
  exclude:
    - '**/*.g.dart'

full analysis options looks like this: (btw dont judge me for how i placed all the rules)

# This file configures the analyzer, which statically analyzes Dart code to
# check for errors, warnings, and lints.
#
# The issues identified by the analyzer are surfaced in the UI of Dart-enabled
# IDEs (https://dart.dev/tools#ides-and-editors). The analyzer can also be
# invoked from the command line by running `flutter analyze`.

# The following line activates a set of recommended lints for Flutter apps,
# packages, and plugins designed to encourage good coding practices.
include: package:flutter_lints/flutter.yaml

analyzer:
  exclude:
    - '**/*.g.dart'

linter:
  # The lint rules applied to this project can be customized in the
  # section below to disable rules from the `package:flutter_lints/flutter.yaml`
  # included above or to enable additional rules. A list of all available lints
  # and their documentation is published at
  # https://dart-lang.github.io/linter/lints/index.html.
  #
  # Instead of disabling a lint rule for the entire project in the
  # section below, it can also be suppressed for a single line of code
  # or a specific dart file by using the `// ignore: name_of_lint` and
  # `// ignore_for_file: name_of_lint` syntax on the line or in the file
  # producing the lint.
  rules:
    # Style rules 
    camel_case_types: true
    library_names : true
    avoid_catches_without_on_clauses: false
    avoid_catching_errors: true
    avoid_empty_else: true
    unnecessary_brace_in_string_interps: true
    avoid_redundant_argument_values: true
    leading_newlines_in_multiline_strings: true
    directives_ordering: true
    # Formatting
    prefer_single_quotes: true
    lines_longer_than_80_chars: true
    curly_braces_in_flow_control_structures: true
    avoid_print: true
    always_specify_types: false
    sort_constructors_first: true
    always_use_package_imports: true
    avoid_dynamic_calls: true
    # Doc comments
    slash_for_doc_comments: true
    require_trailing_commas: true

# Additional information about this file can be found at
# https://dart.dev/guides/language/analysis-options

[srawlins]

The authors of code generators can now suppress all lint in a generated file with // ignore_for_file: type=lint: https://dart.dev/guides/language/analysis-options#suppressing-rules-for-a-file

[srawlins]

I'll go ahead and close this issue with that solution.

[Nikzed]

.analysis_options allows to exclude files #139

analyzer:
  exclude: 
    - '**/*_generated.dart'

No idea of the for of the patter is correct.

lovely