Repository navigation
Don't include dev_dependencies in native build scripts #45714
Description
Use case
I'm maintaining a package providing bindings to sqlite via dart:ffi. For Android apps, we need to compile sqlite3 as a dynamic library that gets put into the apk. For iOS and non-Flutter Dart apps, we use the sqlite3 library from the system, if available.
Since dart:ffi is still in an early stage, many users want to use native bindings for tests only, and use another package like sqflite for production. Unit tests are run on a desktop machine, so we don't compile any native libraries and instead use the one from the system. Unfortunately, the Flutter tool will include the native build script even if the package is just a dev_dependency. This means that native libraries are added into the built apk for no reason, but are still increasing app size.
Proposal
The dev_dependecies section of a pubspec indicates that a package is only used for development. So, I believe that the Flutter tool should not view packages in dev_dependencies as a native package and not run their native buildscripts when using flutter run or flutter build.
Activity
jonahwilliams commentedon Nov 27, 2019
Background: Currently the flutter tool does not distinguish between dependencies and dev_dependencies when determining which plugins to include. Removing plugins from dev_dependencies would be straightforward, except in cases where users are currently depending (accidentally or otherwise) on the current behavior.
simolus3 commentedon Nov 28, 2019
I know that this would technically be a breaking change, but I doubt that there are a lot of users including plugins as a dev-dependency. If I submit a PR for this, do you think this it's reasonable to change the current behavior?
Maybe I can also write a small script to detect plugins that would be removed based on a
pubspec.lockfile so users can know if they're affected beforehand.jonahwilliams commentedon Nov 28, 2019
Thinking about it some more, I'm not so worried about it breaking users as I don't think you could actually use the dart side of the corresponding plugin.
The change would have to be here: https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/plugins.dart#L290
Currently it pulls all plugins from the .packages file, which contains the flattened dependency graph for both dependencies and dev_dependencies. If there is a pubspec present (not required to be), you would have to subset this graph so that it only included the
dependenciessection and their transitive dependencies.jonahwilliams commentedon Sep 26, 2020
This is currently blocked on a resolution for package:integration_test
bartekpacia commentedon Dec 16, 2022
What do you mean by this?
bartekpacia commentedon Dec 19, 2022
After learning more about this issue over the last day, I think I understand what state it is in.
A plugin defined in
dev_dependenciescannot be just ignored when building an app binary, because there are some specialized cases (for example, integration_test) that require that the native code of the plugin defined indev_dependenciesto be available.It looks to me that the decision to include a plugin in the app binary cannot be based solely on whether it is defined in the app's
dev_dependencies. The tool also needs to know if the app we're building requires it, for example:and I'm not sure how this can be achieved currently.
--debug/--profile/--releaseflags toflutter builddon't directly map to whether we're testing an app. A user might want to test a--releasevariant of their .apk.github-actions commentedon Jul 11, 2025
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.