Repository navigation
Strip plugins created from dev_dependencies from release-mode apps #56591
Description
Activity
I think, ideally, it would be possible to include or not include a plugin based on a build flag or somesuch.
for integration_test (formerly known as e2e), we need some way to include the plugin in builds that need it, and strip it out for builds that do not.
IOW, it seems like it'd be very nice if the tool could do something like this: if a plugin is in dev_dependencies, ignore it unless building for a test target (do not add it to any generated files for "regular" builds).
We'd need some meaningful way to discriminate between test builds and non.
Reacted by Bartek PaciaIt's very similar, although I guess this one is proposing a specific solution to it that's a bit different from what I'm suggesting.
yeah, that can be added to
.flutter-plugins-dependencies.IOW, it seems like it'd be very nice if the tool could do something like this: if a plugin is in dev_dependencies, ignore it unless building for a test target (do not add it to any generated files for "regular" builds).
That probably requires generating a new plugin registrant based on which target the user is running. In Objective-C you could use compile-time constants passed to Xcode, right @jmagman ?
When do we re-generate the GeneratedPluginRegistrant code?
pub get, currently
flutter/packages/flutter_tools/lib/src/plugins.dart
Lines 1172 to 1183 in bb29c88
That probably requires generating a new plugin registrant based on which target the user is running
Why would the native-side app ever need to register dev_dependencies?
Why would the native-side app ever need to register dev_dependencies?
Because for integration_test, it has to report test results up to the native side test harness - e.g. to XCTest or JUnit.
Then shouldn't the test target be handling the registration?
26 remaining items
Ok here is a potential crappy algorithm:
- Create a
Set<String> devDependencies - Create a sub-set
nonDevDependencies = dependencies.difference(devDependencies) - Recurse
nonDevDependencies, and remove dependencies of each fromdevDependencies
... and I think you're left with a set of
devDependenciesThatAreOnlyUsedAsSuch?- Create a
Yeah, I think in practive plugins depending directly on other plugins is very rare and I wouldn't be too worried about it.
It's common enough for things like path_provider and such.
Let me see if it's fairly trivial, and if not we can re-think.
I guess I don't really see what the problem is. Yes
bar_pluginis a dev_dependency, but dev_dependency doesn't mean "must exclude from build", it just means "not included by default" If you have another depdency link to bar_plugin then we're still doing what you asked.The problem is we need to know what plugins to exclude, in which what heuristic we're using is "plugins that are exclusively used as dev_dependencies". Exclusively is the part that requires a bit of computation.
Maybe there is an easier way to approach this and I'm missing something?
I think exclusively in dev_dependencies is the right way to think about it.
Exclusively is the part that requires a bit of computation.
Yeah that part is unfortuante
I have to head off for a bit, but basically I'd be implementing this: #157462.
- added a commit that references this issue
on Nov 7, 2024 - changed the title
[-]Do not create plugins from dev_dependencies[/-][+]Strip plugins created from `dev_dependencies` from release-mode apps[/+]on Nov 19, 2024 As of the latest master (#160289), this is enabled by default for
--releasemode apps for all platforms (the plugin automatically becomes inert). Android also removes the dependencies, but iOS, Web, and Desktop do not; however that last bit as an optimization is not covered here.Marking done!
Reacted by Francesco IapiccaThis 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.- locked as resolved and limited conversation to collaborators
on Mar 8, 2025
2024-11-21 update from @matanlurey:
.flutter-plugins-dependenciesformat in the Flutter Gradle plugin #157949 /cc @camsim99Currently the flutter tool creates a plugin for all package dependencies, even though in the dev_dependencies section. We'd like to remove this behavior, since it can lead to plugins used for testing accidentally getting included in released builds. This will be a breaking change, so we can proceed in several steps.
Compute both the current and dependencies-only plugin list and use the current strategy. If discrepancies are found, print a warning that this will be disabled in a future release and how to fix.
Compute both the current and dependencies-only plugin list and use the dependencies only strategy. If discrepancies are found, print a warning/notification that certain plugins have been disabled and include how to fix.
Remove the current strategy, remove the warning.