Use case

Code generation has became a big part of flutter development, I'm currently using it for:

1. Generating i18n strings.
2. Generating asset paths.
3. Generating json parsing.
4. Generating moor database handling.

Unfortunately, the experience related to code generation is not as good as it should be:

1. Code generated files are checked by analyzer for styling problems.
2. I need to setup build_runner for every project and tell people how to use it.
3. I need to remember to run build_runner.
4. Build runner takes many seconds to build.
5. During build process, generated code gets deleted, and analyzer errors are being displayed.
6. Using a code generator requires boilerplate setup for each class:
   a. Adding part directive.
   b. Adding factory methods that delegate constructors to the generated class.
7. Generated files pollute my project's workspace, project wide text search returns results from generated code.
8. Analysis exclude does not work properly: The "exclude" list in .analysis_options is ignored by the dartanalyzer cli dart-lang/sdk#25551, and if it worked properly, then I would not see errors.

I am aware that some of these problems have partial solutions, such as using snippets, configuring IDE to run build_runner task, and so on. I just don't think it's good enough if everyone who uses code generation needs to do it on their own.

Proposal

Code generation should be completely seamless. Below are my suggestions that would achieve this. I realize that some of them may be infeasible.

1. Code generation should be integral part of build process. IDE must generate code automatically and keep it up to date.
2. All generated code should be send to build cache, unless I'm publishing a package.
3. Analyzer should not show any errors if code is not generated.
4. Analyzer should show generation errors. The errors should be as descriptive as possible.
5. Code generation should be fast.
6. It should be possible to code generate static methods and costructors for the annotated class.
7. 'part' directive should not be needed. Adding annotation should be enough.
8. If there are any errors in generated code, they should be treated as code generation errors. Styling issues should be ignored completely.

Example

Using json_serializable as example, here is current state of things:

dependencies:
  json_annotation: ^3.0.1

dev_dependencies:
  build_runner: ^1.8.1
  json_serializable: ^3.3.0

import 'package:json_annotation/json_annotation.dart';

part 'example.g.dart';

@JsonSerializable(nullable: false)
class Person {
  final String firstName;
  final String lastName;
  final DateTime dateOfBirth;
  Person({this.firstName, this.lastName, this.dateOfBirth});
  factory Person.fromJson(Map<String, dynamic> json) => _$PersonFromJson(json);
  Map<String, dynamic> toJson() => _$PersonToJson(this);
}

And here is what I would like to write:

builders:
  json_serializable: ^3.3.0

import 'package:json_annotation/json_annotation.dart';

@JsonSerializable(nullable: false)
class Person {
  final String firstName;
  final String lastName;
  final DateTime dateOfBirth;
}

Benefits

1. Parsing jsons will become pleasant experience.
2. People will start writing smaller code generators that were too infeasible/cumbersome before.
3. People will start experimenting with different approaches to flutter. See: Reusing state logic is either too verbose or too difficult #51752 (comment)
4. Inexperienced flutter devs will be able to use it.

Links

1. Code generation experience in C#