Improvements for generator authors

[davidmorgan]

Overall tracking issue for quality of life improvements for generator authors.

For example this comment "... lack of documentation ... certain things we're likely to want or need are not evident".

[TekExplorer]

Yeah. For example; what is all the "2" stuff? why does it matter? whats the difference? how can i look up a package? a specific class? how do tell if a class is imported already? how do i work with DartType? (TypeVistor!) how do deal with type parameters? DartType's are instantiated types right? that means if there's any parameters, they are specified, even if its with dynamic right? do elements specify type parameters? elements are to Future what DartType is to Future<T> right? can i turn an annotation into the actual object? if so how? (otherwise i dynamically work with DartObject i presume. probably want an extension type. might even want a generator for that too) what even is NullabilitySuffix.star?

and one of the most important: how do i turn this (type) into code?

I imagine most of that can be answered with proper documentation, and improved api can be made later, possibly through wrappers or improving the api directly

[jakemac53]

Note that the APIs discussed in the linked comment are analyzer APIs and not directly related to this package. So, something should probably be filed on the analyzer if we want those APIs to be more well documented.

[rrousselGit]

It's related. Writing generated can be though in part because Analyzer needs to be learned.

But in terms of code-gen, I think APIs are that crutially missing are:

• A way to make it simpler to deal with import prefixes
• Something to insert a DartType in the generated code (getDisplayString is not recommended for this, but we have nothing else) (it should have proper prefix support too)

As it is, we can inspect code, but we don't have any help for writing code

[TekExplorer]

It's related. Writing generated can be though in part because Analyzer needs to be learned.

But in terms of code-gen, I think APIs are that crutially missing are:

• A way to make it simpler to deal with import prefixes

Actually not really necessary since parts can have imports now, so we can just sort of ignore that.

• Something to insert a DartType in the generated code (getDisplayString is not recommended for this, but we have nothing else) (it should have proper prefix support too)

Yes! I think I've managed to make a utility that converts a dart type into a code_builder reference, but if you aren't using code builder, it can be really annoying.

As it is, we can inspect code, but we don't have any help for writing code

Yup!

[davidmorgan]

Code to support writing generators sounds good to me.

It would probably make sense to pull source_gen into the new build_runner effort.

Performance first :)