Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flutter tool extensibility support #13834

Closed
mit-mit opened this issue Jan 2, 2018 · 7 comments
Closed

Flutter tool extensibility support #13834

mit-mit opened this issue Jan 2, 2018 · 7 comments
Labels
c: new feature Nothing broken; request for a new capability tool Affects the "flutter" command-line tool. See also t: labels.

Comments

@mit-mit
Copy link
Member

mit-mit commented Jan 2, 2018

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

@mit-mit mit-mit added tool Affects the "flutter" command-line tool. See also t: labels. c: new feature Nothing broken; request for a new capability labels Jan 2, 2018
@fmatosqg
Copy link
Contributor

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
Copy link
Contributor

fmatosqg commented Apr 25, 2018

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
Copy link
Contributor

Related: #16603 #15545 #20865

@tvolkert
Copy link
Contributor

Closing as a dup of #25377

@allComputableThings
Copy link

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
Copy link
Contributor

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

@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
c: new feature Nothing broken; request for a new capability tool Affects the "flutter" command-line tool. See also t: labels.
Projects
None yet
Development

No branches or pull requests

7 participants