Introductions

[davidmorgan]

Hi everyone! As you may have figured out by now, a direct result of the cancellation of macros is that I'll be working on build_runner for a while. So I thought I'd introduce myself so y'all know a bit what to expect.

Please call me "Morgan" :) ... my first name is "David" but I don't use it for work as I often find myself on a team with more than one "David". Precise naming is useful ;)

I've been at Google for 17 years(!).

The first big thing I worked on was AdWords, which was using GWT, the "Google Web Toolkit", a Java->Javascript compiler. That's what I was working on when I discovered Dart, and pushed for my team to be an early adopter, before being part of the whole-AdWords rewrite to Dart. I wrote built_collection and built_value and gave a talk about them at a Dart developer conference.

Right after giving that talk in 2016 I joined the Dart team--sort of. I worked on fully Google-internal Dart infrastructure: bazel builds, codegen, dev tools, SDK integration. I've spent a lot of time benchmarking dev cycles and making them faster.

At the start of 2024 I switched from working on Google-internal things to things y'all care about :) and joined the macros effort.

The tl;dr is that I'm very much into Dart codegen, dev tools, and fast dev cycles; and hopefully with lots of useful experience to apply to the problem; but also still a newbie when it comes to the internals of Dart SDK tooling and build_runner itself.

Since I've been mostly focused on Google-internal things I also haven't interacted much with "the community", except via the built_value issue tracker :) ... that should change I think, I look forward to hearing more about what people want from codegen and figuring out what we can do.

Edit: I should have ended on a question to encourage people to say "hi". So ... ehhm ... what's your top three wish list for improvements to build_runner this year?

[cedvdb]

Hello Morgan,

While I may not be the best person to provide feedback since I've not invested time in build_runner, the reasons I haven't may be relevant.
I personally would like it to be as invisible as possible in regards to my current workflow (which does not include build_runner):

• Incorporating it to the dart sdk, I should not have to install an external package. It a small thing but I think it matters. I understand that one of the reason is versioning but I believe the pros outweight the cons, it's not like build_runner is updated weekly, so it could follow the dart sdk releases.
• I think running the runner automatically at the start of a normal dart build should be considered, if things can be properly cached.
• The documentation should be improved, going through it right now, I did not find a simple code transformation example. (i went over the md files, quickly, as one would to get going). There should be the simplest example available just to get going, a quickstart if you will, a simple data class example should also be included in a separate md.
• This also mean that I would not want to wait minutes for code generation, which was also one of the reason for me to drop its usage.

I would like my code base to stay clean and tidy:

• I don't want x.g.dart files scattered, it decrease readability, the output dir should be configurable imo.
• Currently some build generation packages require you to have lines like class Person with _$Person, the with _$Person always felt hacky and was one more reason to not use a builder. With the advancement in the augmentation part, I guess that may be problem solved.

Quick random fact for you, I checked because I was under the impression that Morgan was common in the US. 15 Morgans for every 100 000 Americans and 1500 Davids.

[davidmorgan]

Hi :) ... and thanks for the feedback!

Those are all great points, I'm almost 100% in agreement. I do like having package:build outside the SDK for now since I expect to make rapid changes to it ;) but we'll definitely look at ways to integrate it more tightly into everyone's workflows.

I'm fully focused on performance right now; when that's under control I think "quality of life" for generator users is probably next on the list: so, more stable, better-integrated into workflows.