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.

[PvtPuddles]

I don't want x.g.dart files scattered, it decrease readability, the output dir should be configurable imo.

For what it's worth, I've been super pleased with IntelliJ's file nesting.

Dart already has a bunch of file nesting rules for dart.js, .dart.js.map, etc. I went ahead and added a couple rules for .g.dart and .freezed.dart, and it's cleaned up very nicely.

It would be nice if the dart plugin included at least the .g.dart as a child-type of .dart, but setting that up manually is pretty easy too.

[davidmorgan]

Oh, interesting, thanks.

It turns out VSCode has such a thing too, but it's disabled by default; search in settings for "file nesting".

It helps with vertical space, which is nice; but it causes the filename to be indented with a > that you click to expand/collapse it, which is less nice. Not sure if I'll leave it enabled. But, good to know about :)

[cedvdb]

@PvtPuddles

I use file nesting in visual studio but if some files use generation and others do not, you end up with an uneven structure

[PvtPuddles]

That does sound annoying. I think IntelliJ takes the win on this one :P

[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.

[gmpassos]

For me, the main issue with build_runner is the time it takes to perform a full (non-incremental) build of a large project. Since all our projects currently range from medium to large in size, this takes a significant amount of development time—especially because we use it to generate reflection code, which is used by the backend to automate routes, entity serialization, and more.

[davidmorgan]

Getting close now to a release that will improve performance :) it's been quite a trek.