Prompt plugin authors to add Swift Package Manager compatibility to their plugin

[okorohelijah]

Prompt plugin authors to add Swift Package Manager compatibility to their plugin

Fixes #148222

If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[okorohelijah]

The doc for migrating to spm doesnt seem to include adding the FlutterFramework dependency. I plan on updating it

[gemini-code-assist]

Code Review

This pull request introduces a validation check to prompt plugin authors to add Swift Package Manager (SPM) compatibility for their iOS and macOS plugins. The check runs when refreshPluginsList is called for a plugin's example app. It verifies if a plugin with a podspec also has a Package.swift file, and if so, whether it correctly depends on FlutterFramework. Warnings are displayed to guide plugin authors on how to add or fix their SPM support. The changes include new logic in flutter_plugins.dart and plugins.dart, along with corresponding unit tests.

[vashworth]

Can you move all logic into DarwinDependencyManagement?

[vashworth]

I think this could be simplified by adding the warning to _evaluatePluginsAndPrintWarnings, which already checks if the plugin is SwiftPM/CocoaPods compatible.

flutter/packages/flutter_tools/lib/src/macos/darwin_dependency_management.dart

Lines 143 to 172 in 6486686

	Future<({int totalCount, int swiftPackageCount, int podCount})> _evaluatePluginsAndPrintWarnings({
	required FlutterDarwinPlatform platform,
	required XcodeBasedProject xcodeProject,
	required bool hostPlatformIsMacOS,
	}) async {
	var pluginCount = 0;
	var swiftPackageCount = 0;
	var cocoapodCount = 0;
	for (final Plugin plugin in _plugins) {
	if (plugin.platforms[platform.name] == null) {
	continue;
	}
	final String? swiftPackagePath = plugin.pluginSwiftPackageManifestPath(
	_fileSystem,
	platform.name,
	);
	final bool swiftPackageManagerCompatible =
	swiftPackagePath != null && _fileSystem.file(swiftPackagePath).existsSync();
	final String? podspecPath = plugin.pluginPodspecPath(_fileSystem, platform.name);
	final bool cocoaPodsCompatible =
	podspecPath != null && _fileSystem.file(podspecPath).existsSync();
	// If a plugin is missing both a Package.swift and Podspec, it won't be
	// included by either Swift Package Manager or Cocoapods. This can happen
	// when a plugin doesn't have native platform code.
	// For example, image_picker_macos only uses dart code.
	if (!swiftPackageManagerCompatible && !cocoaPodsCompatible) {
	continue;
	}

I'd do something like

Future<({int totalCount, int swiftPackageCount, int podCount})> _evaluatePluginsAndPrintWarnings({
   ...
  }) async {
    String? pluginFromExampleApp = _loadPluginFromExampleProject(...);
    for (final Plugin plugin in _plugins) {
      ...
       if (!swiftPackageManagerCompatible && !cocoaPodsCompatible) { 
         continue; 
       } 
      if (plugin.name == pluginFromExampleApp) {
          if (swiftPackageManagerCompatible && !_hasFlutterFrameworkDependency()) {
            _logger.printWarning(...)
          } else if (!swiftPackageManagerCompatible) {
            _logger.printWarning(...)
          }
      }
    }
}

[okorohelijah]

_evaluatePluginsAndPrintWarnings operates on the app's dependency plugins during every build and targets app developers while the validation only fires for plugin example apps, targets the parent plugin being developed, and does a deeper content analysis of the Package.swift (checking for FlutterFramework dependency declarations while filtering out comments). I thought merging them could be be a mix of 2 different things so I kept them separate for clarity wdyt?

[vashworth]

Let's wait for flutter/website#12979 to land, so we can point to the docs