Repository navigation
Cannot reference generated code in .dart_tool in a Flutter project #16603
Description
Background
build_runner looks to be a great tool for meta programming that I'd like to start taking advantage of more in flutter (e.g. by using inject.dart, which is designed to be platform agnostic). By default, when you set up your build.yaml, the build_to value is set to "cache". This means that generated files won't be checked into source control, they'll be generated in a hidden folder: .dart_tool/build/generated. The problem is, flutter projects can't seem to reference files generated in this folder.
Steps to Reproduce
- Clone monzo-flutter
- Switch to branch flutter-bug-1
- Run
flutter packages pub run build_runner buildto build the generated code - Run the project.
Result:
All of the code successfully generated in .dart_tool/build/generated. However the code cannot be referenced from within lib/, hence running the app fails with the following issue:
Your application could not be compiled, because its dependencies could not be established.
The following Dart file:
/Users/brad/Sources/monzo-flutter/lib/app_component.dart
...refers, in an import, to the following library:
/Users/brad/Sources/monzo-flutter/lib/app_component.inject.dart
Unfortunately, that library does not appear to exist on your file system.
Flutter Doctor
[✓] Flutter (Channel master, v0.2.12-pre.33, on Mac OS X 10.13.2 17C88, locale en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 9.3)
[✓] Android Studio (version 3.0)
[✓] IntelliJ IDEA Community Edition (version 2017.3.5)
[!] Connected devices
! No devices available
Activity
zoechi commentedon Apr 16, 2018
If you use
build_to: sourceyou still can use.gitignoreto excludelib/**/*.g.dart(or similar)@jakemac53
@natebosch
Is this supposed to work this way?
jakemac53 commentedon Apr 16, 2018
We don't have tight integration with flutter yet, and unfortunately I don't know enough about flutter to know what the "correct" solution is here.
We do have the ability to create a merged output directory (
-o <dir>) which flutter could use, and has a valid .packages file.Unfortunately due to the limitations of .packages files we can't just expose a valid one directly in the root package (think like .build.packages or something), because files can live in 2 locations (sources live in pubcache, generated files live in .dart_tool).
So yes, for now only
build_to: sourcebuilders are going to work with flutter out of the box.natebosch commentedon Apr 16, 2018
cc @yjbanov
grandstaish commentedon Apr 16, 2018
I can confirm that changing
build_totosourceworks as a workaround (although it clutters up the source files a bit). However, I can't see a way to way setbuild_tofrom anywhere other than theinject_generatorlibrary itself (as in, in my own copy of the library). It seems that consumers of the library can't modify this value, only enabled, generate_for, and options. Is that true or am I doing this wrong?jakemac53 commentedon Apr 16, 2018
Yes - that is accurate. It is a bit complicated but generally we want/expect the builder authors to set this. The reason is that some builders really should be
build_to: cache. If their generated code depends on code from packages you depend on, then it isn't safe to publish those files with your package since their content depends on a particular version solve.However - this logic doesn't really hold for application packages that never get published, and the convenience/utility of having them in the source tree means we might want to revisit that decision. It is primarily a philosophical limitation not a technical one.
natebosch commentedon Apr 16, 2018
You are correct,
build_tois not something we expect users to set. Generally Builder authors are in a better position to understand whether it is safe topub publishwith the outputs of the Builder. If the generated code depends on other packages in the version solve and might not work with a different version solve in pub, then it shouldn't be published.natebosch commentedon Apr 17, 2018
After some discussion we will look at whether we can allow consuming code to override this option. dart-lang/build#1303
yjbanov commentedon Apr 25, 2018
We (well, at least I) would like to add formal support for
build_runnerin Flutter tools in a way that would obviate the need for extra options. Ideally you would add a dependency onpackage:injectin yourpubspec.yaml, sprinkle some@provide/@injectorannotations and have the build system take care of the rest. This will require some planning and effort though. In the mean time workarounds such asbuild_tois the way try things out.jimsimon commentedon Jan 25, 2019
As an aside (and since I can't create issues on inject's repo), it may be worthwhile to mention some of the limitations for using inject with flutter. For example, you need to override the
build_tovia ainject_generator.build.yamlfile. It also doesn't support named constructor parameters which are used pretty heavily in flutter. Right now the README for inject says "it works perfectly well with flutter", which feels a little misleading.Edit: It also appears to lack support for generics, which makes using strong types with Redux impossible.
jonahwilliams commentedon Jan 25, 2019
FWIW, I am working on build_runner integration currently and that includes having flutter understand the .dart_tool generated directory. See #25377 (comment)
Re: build to source vs cached - the problem with building to source is that by mixing up source files and generated files you lose the ability to know that something is safe to overwrite. If you generate code once and forget about it that is okay, but if you want a hot reload workflow based around codegen its a real drag.
jonahwilliams commentedon Jan 28, 2019
If you're interested in this issue, please follow (and thumbs up) #27141
jonahwilliams commentedon Mar 22, 2019
Closed via #29399, please see #27141 for more information.
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.