Find a solution for single-add situations like utility methods

[natebosch]

Sometime a Generator can run 1 or more times on a library. It might want to write some code that should only appear once in the output, regardless of how many elements were run. Potential use cases are utility methods, and (maybe?) imports for standalone builders.

A few ways we could solve this:

1. Add an argument to the Generator.generate method that has an explicit way to add a utility method and knows it should only add it once.
2. Make the Generators run more explicitly serially and operate on a StringBuffer or similar so they can see previous content and check whether it contains certain strings already.
3. Change the api Generator.generate(List<Element> elements, BuildStep buildStep) and have it run once per library with all elements available together.
4. Add some sort of 'context' object, maybe a Map<String, Object>, which gets passed repeatedly to each Generator and allows it to communicate with itself across elements in the library.

cc @matanlurey

[matanlurey]

At least for Angular we are planning on using code_builder.

If I could pass an Allocator object, via a context or otherwise, sure!

[natebosch]

My initial thoughts:

1. I like that it is explicit about the use case it is solving which makes it less confusing, though every new use case that comes up we might need to handle separately. Can't solve imports and utilities in the exact same method AFAICT so would be some tricky apis to work out and imports only apply to standalone builders etc.
2. We'd be handcuffing ourselves on performance...
3. I like this. We could possibly combine Generator, GeneratorForAnnotation, and GeneratorForLibrary (from Add GeneratorForLibrary #220) into a single interface with generate(LibraryElement element, BuildStep buildStep) and just have utilities for going from LibraryElement to List<Element> or List<AnnotatedElement> as needed. It does feel like we'd be making some of the really simple cases harder, but we'd be making the complex cases easier.
4. I'd like to avoid this. It's maybe too general and raises questions about how it should be used and why.

[matanlurey]

/shrug. Let's wait until we run into this as a concrete problem before prioritizing.

[natebosch]

I'm running with solution 3 which has the added bonus of solving #220

One thing that makes this tricky is that it's a breaking change in behavior, but not in the analyzer.

class Generator {
  Future<String> generate(LibraryElement element, BuildStep buildStep);
}

class Foo extends Generator {
  // This is valid but won't do what you want!
  @override
  Future<String> generate(Element element, BuildStep buildStep);
}

[kevmoo]

...unless you rename the method? (which is omitted in the copy-paste above?)