Flutter tool extensibility support

[mit-mit]

It's not sustainable for the flutter tool to support all the commands that all developers collectively desire. It's much more sustainable to support an extensibility model where the tool itself can be extended by adding in "tools plugins".

• Run Dart commend / do codegen: flutter dart foo.dart to run dart foo.dart with FLUTTER_ROOT set #13607
• Generate app icon: Aided generation of platform-specific app icons #10387
• Determining the size of an app: I wish I could preview and audit my release size #13189
• Customize the build: Developers would like to extend and customize the build scripts for producing their Flutter app #9870

[fmatosqg]

I'd like to see some specs that would allow me to do code generation before build starts.
My proposal is adding a line to pubspec, something like this:

hooks:
  hookFolder/hookScript.dart hookParameter1 hookParameter2

and preferrably extensible to packages in some shape or form, but I'd be happy to develop based on the above spec to kick it off.

[fmatosqg]

I get the feeling that this pub ... watch thing is popular, although very new to me. And my guess is that it could solve the problem with first class support to both build_runner and watch so they can integrate seamlessly with flutter run
ref #14703.

[eseidelGoogle]

Related: #16603 #15545 #20865

[tvolkert]

Closing as a dup of #25377

[allComputableThings]

Crazy question -- it seems like a lot of uses of annotations could be support be the language itself, rather that making dependencies on specific build tool (e.g. annotations macros that take a class and return a class, or take a function and return a function). Any plans to support this in the future?

[Levi-Lesches]

@stuz5000 While I completely agree with you, I think that's probably a better issue for the dart-lang/lang repo, where work for Dart itself (not to be confused with Flutter, that uses Dart) is done.