Repository navigation
Strip plugins created from dev_dependencies from release-mode apps #56591
Description
2024-11-21 update from @matanlurey:
- Android work Use updated
.flutter-plugins-dependenciesformat in the Flutter Gradle plugin #157949 /cc @camsim99 - iOS/macOS work integration_test embedded in shipping iOS apps when added to pubspec #74274 /cc @cbracken
Currently 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.
Activity
dnfield commentedon Dec 8, 2020
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.
dnfield commentedon Dec 8, 2020
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.
dnfield commentedon Dec 8, 2020
/cc @blasten @jmagman who probably know a lot more about how or if this could work on Android and iOS.
jmagman commentedon Dec 8, 2020
Is this different from #49101 or #45714?
On the iOS side this would be easy to do if
.flutter-plugins-dependenciesindicated which were dev-only.dnfield commentedon Dec 8, 2020
It'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.
blasten commentedon Dec 8, 2020
yeah, that can be added to
.flutter-plugins-dependencies.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 ?
dnfield commentedon Dec 8, 2020
When do we re-generate the GeneratedPluginRegistrant code?
blasten commentedon Dec 8, 2020
pub get, currently
jmagman commentedon Dec 8, 2020
flutter/packages/flutter_tools/lib/src/plugins.dart
Lines 1172 to 1183 in bb29c88
Why would the native-side app ever need to register dev_dependencies?
dnfield commentedon Dec 8, 2020
Because for integration_test, it has to report test results up to the native side test harness - e.g. to XCTest or JUnit.
jmagman commentedon Dec 8, 2020
Then shouldn't the test target be handling the registration?
26 remaining items
matanlurey commentedon Oct 23, 2024
Ok here is a potential crappy algorithm:
Set<String> devDependenciesnonDevDependencies = dependencies.difference(devDependencies)nonDevDependencies, and remove dependencies of each fromdevDependencies... and I think you're left with a set of
devDependenciesThatAreOnlyUsedAsSuch?jonahwilliams commentedon Oct 23, 2024
Yeah, I think in practive plugins depending directly on other plugins is very rare and I wouldn't be too worried about it.
matanlurey commentedon Oct 23, 2024
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.
jonahwilliams commentedon Oct 23, 2024
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.matanlurey commentedon Oct 23, 2024
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?
jonahwilliams commentedon Oct 23, 2024
I think exclusively in dev_dependencies is the right way to think about it.
Yeah that part is unfortuante
matanlurey commentedon Oct 23, 2024
I have to head off for a bit, but basically I'd be implementing this: #157462.
`Plugin.isDevDependency` if exclusively in `dev_dependencies` (#157462)
[-]Do not create plugins from dev_dependencies[/-][+]Strip plugins created from `dev_dependencies` from release-mode apps[/+]matanlurey commentedon Feb 22, 2025
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!
github-actions commentedon Mar 8, 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.