Linter warnings should be ignored

[VictorUvarov]

First of all great package!

If you use something like pedantic in your flutter/dart project you can receive linter warnings and errors to help improve productivity.

• I think it is possible to hide linter warnings from generated files, but I think it would be better for the generator to ignore them itself. I know built value already does this.
• Built value currently adds this line to the bottom of the generator

// ignore_for_file: always_put_control_body_on_new_line,always_specify_types,annotate_overrides,avoid_annotating_with_dynamic,avoid_as,avoid_catches_without_on_clauses,avoid_returning_this,lines_longer_than_80_chars,omit_local_variable_types,prefer_expression_function_bodies,sort_constructors_first,test_types_in_equals,unnecessary_const,unnecessary_new

• The specific linter warnings i get from this package are:

unnecessary_const

This can be...

specifiedType: const FullType(List, const [const FullType(Post)]))

changed to this...

specifiedType: const FullType(List, [FullType(Post)]))

unused_element

If i don't use a serializer i get this warning for my HomeViewState union

The declaration '_$homeViewStateSerializer' isn't referenced.
Try removing the declaration of '_$homeViewStateSerializer'.

unnecessary_new

which comes from the serializer

Serializer<HomeViewState> _$homeViewStateSerializer =
    new _$HomeViewStateSerializer();

[realcr]

@VictorUvarov: Hey, thanks for reporting this issue! I was seeing the linter hints coming from built_value, though until you added this issue I never realized why they were there. I agree that it will be very useful to add those hints.

I see things on two levels:

1. It is very likely that built_union's code generator can be improved a bit to emit better code, and this will eliminate some of the linter warnings.
2. Some linter warnings can not be fixed at the code generation phase. One example is unused_element (as you pointed out). This happens because during generation time we have no way to know which code parts will be used.

The way I see it, the general plan of action should be to first attempt to fix anything that can be fixed in section (1), and only the rest of the linter warnings should be solved using a linter ignore hint (2).

I am super busy for the following next weeks, I was wondering if you would like to take a stab at solving some of the lints you mentioned? I know it might be a lot to ask, so please don't feel obliged to take on this task.
If you are interested, please make sure to check the short hacking-guide.

[VictorUvarov]

For now i'm just ignoring all generated files in my lib folder

include: package:pedantic/analysis_options.1.9.0.yaml

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

I think the best thing to do is just add the ignore file comment just like built_value does. I'm not sure where to put the code yet.