Investigate source-gen observables

[jakemac53]

See https://github.com/sigmundch/observe_gen for an example. If we are willing to commit to using the source-gen package, then we can potentially get rid of all the set boilerplate.

[donny-dont]

How would source_gen impact users? I thought one of the benefits of transformers was the ability to iterate quickly.

[jakemac53]

A big part of this task is to asses the overall workflow impact. Source generation should be fast, but we haven't really experimented with it in practice. Also I think the current version of source_gen uses build.dart to know when to rerun, and that is an editor-specific thing so we will need some other solution around that. It will likely require some other changes to the source_gen package to get the turnaround speeds that we want (it does whole program resolution).

[jakemac53]

ping @kevmoo for more info on source_gen and any ideas he has around this

[donny-dont]

So is there a particular reason to use transformers if you can hook into build.dart? That's something I'm a bit fuzzy on as well.

[jakemac53]

Basically, they can both be good for different things. Transformers are better for code that you don't want to check into the repo, like deploy time optimizations/etc. Code generation is better in many ways for stuff that just removes boilerplate, or to generate code that you would otherwise need mirrors to implement. The more that we move things to code generation the more similar your deployed code is to the code you see in your ide as well.

[jakemac53]

Also build.dart is not supported in any other ide other than the editor, so there is that. You would need to run write a separate file watcher otherwise, and we will probably need to make something like that.

[donny-dont]

Yea sorry getting a bit meta as this is something I've been debating with one of my own libraries. Wasn't sure which is the better way to go and can see cases for wanting to check in generated code but other times it being too in flux to be a good idea. That would be a strike against the source_gen route but I wasn't sure if the dart team was moving away from transformers.

[jakemac53]

Transformers have to rerun from scratch every time you start pub build or pub serve, so they are inherently slower. They are also notoriously hard to debug, so yes we are trying to explore other options.

[kevmoo]

@donny-dont build.dart is/was only in Dart Editor. I'm very invested in coming up with a solution that will work "everywhere" – stay tuned.

[a14n]

I used pub transformer and source_gen for js wrapping and I confirm that transformers are really boring to debug.

Actually it seems that transformers are used as an optimization to get ride of mirrors for dart2js (in the context of code generation). That another drawback because you have to handle 2 versions (one for mirrors and one for transformer) if you don't want to be linked to transformers.

On the other hand, transformers allow some deeper code changes. With transformers you can add/modify/remove everything. With source_gen you can only add new content.

@kevmoo : I planned to make a PR that adds an executable to watch file changes (with FileSystemEntity.watch) but it seems I'm late :) BTW perhaps the source_gen package is not the good target and a new package could be created to have the same behaviour as the Dart Editor with build.dart. What do you think?

[kevmoo]

@a14n any work you want to do on the file watching side would be goodness.

We're a way off from doing this work ourselves. You may learn some things that will be helpful.

[sigmundch]

Besides FileSystemEntity.watch - it might be worth taking a look at https://pub.dartlang.org/packages/watcher.

[a14n]

@kevmoo : I just published build_system to call automatically build.dart on every file changes (like the Dart Editor did).

@sigmundch : thanks for the link to watcher... It helped a lot!

[kevmoo]

Great to see, @a14n. I'll look into mentioning that on the source_gen package page.