You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
build and source_gen are the reference for code-generation in dart.
Flutter having disabled dart:mirror, code generation is very important (notably for serialization).
The problem is, the current code-generation workflow is a bit tiresome
First, the command to generate code is the following:
flutter pub pub run build_runner build
There's far too many repetitions for a relatively common command. It would be much better to have the following (and maybe removing build_runner from the project direct dependencies):
flutter generate --watch
This would make things much smoother and intuitive
Once we've got this command we can then add a few flags to run:
flutter run --[no-]generate
Which would run a flutter generate --watch in background. So that there's no need for multiple terminal instances.
As a bonus point, flutter run could detect if the project has a dependency or not on build (even indirect), and decides accordingly whether to generate dart files or not.
I think this is related to #13834 perhaps a dup of the linked #9870
That can help. But I fear that the linked PR may make project bootstrap harder. And this issue is not so much about plugins or builds hooks.
In the end, almost all projects will want a [de]serializer. And since the official solution is code-generation, I think flutter should make it a "working out of the box" experience.
We will want code gen to be integrated into Flutter's build system so that it can run before analysis in the analyzer server, before tests in flutter test, and during hot reload.
Reacted by Luke Pighetti, Remi Rousselet, Emrah Bilbay and SAGAR SURI
We could do so by basing flutter's internal build steps (test, hot reload, build) on package:build. This would allow us to integrate with existing builders and source gen, as have a better story for testing our own build
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.
Activity
zoechi commentedon Aug 21, 2018
I think this is related to #13834 perhaps a dup of the linked #9870
jonahwilliams commentedon Aug 21, 2018
While I agree we should improve this workflow, as a temporary workaround I would just create an alias for the build runner command.
alias pbr="flutter pub pub run build_runner build"rrousselGit commentedon Aug 21, 2018
That can help. But I fear that the linked PR may make project bootstrap harder. And this issue is not so much about plugins or builds hooks.
In the end, almost all projects will want a [de]serializer. And since the official solution is code-generation, I think flutter should make it a "working out of the box" experience.
Hixie commentedon Dec 12, 2018
We will want code gen to be integrated into Flutter's build system so that it can run before analysis in the analyzer server, before tests in
flutter test, and during hot reload.[-]Improve code-generation workflow[/-][+]Code generation[/+]jonahwilliams commentedon Dec 12, 2018
We could do so by basing flutter's internal build steps (test, hot reload, build) on
package:build. This would allow us to integrate with existing builders and source gen, as have a better story for testing our own buildtvolkert commentedon Dec 19, 2018
Depends on #25377
rrousselGit commentedon Jan 11, 2019
I recently faced Flutter throwing an exception because hot-reload applied before a code-generator could finish.
The solution is likely in implementing this issue. But is there anything I can do in the meantime to prevent this from reproducing?
jonahwilliams commentedon Jan 25, 2019
See #25377 (comment)
jonahwilliams commentedon Mar 22, 2019
Closed via #29399. See #27141 for more info
github-actions commentedon Aug 15, 2021
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 -vand a minimal reproduction of the issue.