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
{{ message }}
Repository navigation
build_runner can't compile its build script because Amplify pulls in native-asset/"build hooks" packages (sqlite3/jni) #10933
build_runner can't compile its build script because Amplify pulls in native-asset/"build hooks" packages (sqlite3/jni), and that combination is currently broken in Dart's tooling (dart-lang/native#2792).
This is a known structural conflict between Dart's newer Native Assets (Build Hooks) feature and how build_runner compiles its isolated build scripts.Because build_runner uses dart compile under the hood to compile your build script (.dart_tool/build/entrypoint/build.dart) into an AOT snapshot, it triggers a hard failure when a package like AWS Amplify introduces transitive dependencies (sqlite3, jni) that declare Native Assets build hooks. Currently, dart compile completely blocks compilation if any dependency in the tree uses build hooks.Until the underlying issue in Dart's native toolchain (dart-lang/native#2792) is patched, you can use these workarounds to unblock your code generation:
I found a couple of solutions, but is there a main solution?
Workaround 1: Force JIT Compilation (Bypass AOT Snapshotting)You can force build_runner to run using the Dart VM in JIT mode rather than attempting to compile the entrypoint script into an AOT executable.Run build_runner with the --no-precompile flag:
Workaround 2: Downgrade Packages to Pre-Native-Asset VersionsIf you do not want to change your build commands, you can temporarily downgrade the transitive packages to versions released before they adopted Native Assets build hooks.Add explicit dependency_overrides in your pubspec.yaml to pin sqlite3 and jni down to versions that do not utilize hook/build.dart:
Workaround 3: Decouple Build Tools into a Local Package SplitIf neither of the above works comfortably for your workflow, separate your code-generation tools (like freezed, json_serializable) from your main application. You can isolate a smaller local Dart package that holds your data models and code generation dependencies, ensuring Amplify is never pulled into that package's dependency tree.
changed the title [-]Feedback for “Guide: Dart/Flutter”[/-][+]build_runner can't compile its build script because Amplify pulls in native-asset/"build hooks" packages (sqlite3/jni)[/+]on Sep 3, 2026
@eddeee888
Thanks for looking into this. To answer directly:
Is it related to graphql-code-generator? Only indirectly. flutter-freezed generates .dart files annotated with @freezed/@JsonSerializable. Those annotations require a separate dart run build_runner build pass (freezed/json_serializable codegen) inside the consuming Flutter project to produce the .freezed.dart/.g.dart files — that step isn't invoked by graphql-code-generator itself, it's a normal part of any freezed-based Flutter project. The failure happens in that step, not in codegen's own generation logic.
The reason it's worth reporting here rather than purely on dart-lang/native is that any Flutter project using flutter-freezed-generated models alongside AWS Amplify (amplify_flutter, which pulls in sqlite3/jni transitively) will hit this the moment they try to build the generated code — so it's a real, predictable pain point for this plugin's users even though the root cause is upstream in Dart's tooling (dart-lang/native#2792: build_runner's AOT-compiled entrypoint hard-fails when any transitive dependency declares a native-assets build hook).
Minimal repro:
New Flutter project, add freezed, freezed_annotation, json_serializable, build_runner as usual.
Add amplify_flutter (any recent version) as a dependency — this is what pulls in sqlite3/jni with hook/build.dart.
Generate (or hand-write) one @freezed class, e.g. the output shape from flutter-freezed.
Run dart run build_runner build.
It fails compiling the build script's AOT snapshot because of the native-assets build hooks in the dependency graph — unrelated to the freezed class itself, reproducible with zero graphql-code-generator involvement once Amplify is in the pubspec.
Workaround: dart run build_runner build --no-precompile forces JIT instead of AOT and avoids the failure.
Given the root cause is Dart tooling, not graphql-code-generator, maybe the right resolution here is a note in the flutter-freezed README pointing Amplify users at --no-precompile, rather than a code change — happy to send a docs PR for that if useful.
Activity
[-]Feedback for “Guide: Dart/Flutter”[/-][+]build_runner can't compile its build script because Amplify pulls in native-asset/"build hooks" packages (sqlite3/jni)[/+]eddeee888 commentedon Sep 6, 2026
Hi @mattiLeBlanc , could you please share a bit more about the issue:
eddeee888 commentedon Sep 19, 2026
Closing because it seems unrelated to GraphQL Codegen
mattiLeBlanc commentedon Sep 20, 2026
@eddeee888
Thanks for looking into this. To answer directly:
Is it related to graphql-code-generator? Only indirectly. flutter-freezed generates .dart files annotated with @freezed/@JsonSerializable. Those annotations require a separate dart run build_runner build pass (freezed/json_serializable codegen) inside the consuming Flutter project to produce the .freezed.dart/.g.dart files — that step isn't invoked by graphql-code-generator itself, it's a normal part of any freezed-based Flutter project. The failure happens in that step, not in codegen's own generation logic.
The reason it's worth reporting here rather than purely on dart-lang/native is that any Flutter project using flutter-freezed-generated models alongside AWS Amplify (amplify_flutter, which pulls in sqlite3/jni transitively) will hit this the moment they try to build the generated code — so it's a real, predictable pain point for this plugin's users even though the root cause is upstream in Dart's tooling (dart-lang/native#2792: build_runner's AOT-compiled entrypoint hard-fails when any transitive dependency declares a native-assets build hook).
Minimal repro:
New Flutter project, add freezed, freezed_annotation, json_serializable, build_runner as usual.
Add amplify_flutter (any recent version) as a dependency — this is what pulls in sqlite3/jni with hook/build.dart.
Generate (or hand-write) one @freezed class, e.g. the output shape from flutter-freezed.
Run dart run build_runner build.
It fails compiling the build script's AOT snapshot because of the native-assets build hooks in the dependency graph — unrelated to the freezed class itself, reproducible with zero graphql-code-generator involvement once Amplify is in the pubspec.
Workaround: dart run build_runner build --no-precompile forces JIT instead of AOT and avoids the failure.
Given the root cause is Dart tooling, not graphql-code-generator, maybe the right resolution here is a note in the flutter-freezed README pointing Amplify users at --no-precompile, rather than a code change — happy to send a docs PR for that if useful.
eddeee888 commentedon Sep 20, 2026
Ah gotcha, thanks @mattiLeBlanc !
Would this be the guide you are talking about? https://github.com/dotansimha/graphql-code-generator/blob/master/website/content/docs/guides/flutter-freezed.mdx
Happy to review the PR once you sent it through. Thank you
eddeee888 commentedon Sep 20, 2026
Done in #10975
Thank you @mattiLeBlanc