Morgan :)

> actually, IDE support is a brilliant solution for build runner on IDE instead of using `build_runner build--build-filter` I will just tap by mouse on build and voilà it works...

> > It's true that plugins get their own process, but I think it's still not okay to put a build in there: builds are allowed to scale to any...

The way we use the analyzer in google3 solves all these problems, we should probably do something similar. The analyzer supports working from summaries on disk, which means it can...

> That sounds fine for the command-line analyzer, but I don't (at least yet) believe that this will work for the analysis server's use case. I don't think we can't...

I agree with most of that--except, it's okay to have codegen _coordinated_ by an analyzer plugin, but it should not run _in_ an analyzer plugin. There is no build system...

> If running _in_ an analyzer plugin is optional, I don't think that's an issue. > > We would still have a CLI to manually run generation. And we'd likely...

> So, anywhere it's ok to run plugins it should also be ok to run builders, from a performance perspective. That doesn't scale. It might be fast for some examples,...

Closing as stale.

That's certainly something I can look at. What are the advantages of using multiple builders vs just bundling everything as a single builder? Thanks.

> By "shared parts" do you mean a part file that two libraries both include? Sorry, I should have been clearer, I meant the [source_gen feature](https://pub.dev/documentation/source_gen/latest/source_gen/SharedPartBuilder-class.html) which combines the output...