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

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(...)
          }
      }
    }
}

_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?

If you prefer to separate the call path, maybe worth creating a common helper function to be called by both path?

I agree with @hellohuanlin. If we're going to keep them separate, let's move the common logic into a helper function

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

If you prefer to separate the call path, maybe worth creating a common helper function to be called by both path?

nit: it's unclear from the function name that this is for plugin's example app, rather than a regular app. How about something like _validatePluginSwiftPMSupportViaPluginExampleApp

Or _validateExampleAppPluginSupportsSwiftPackageManager

1. Worth commenting how duplicate can happen. (i'm also curious)
2. why static?
3. let's be consistent and pick one among SPM vs SwiftPM vs SwiftPackageManager naming

I don't think this is needed

uber nit: cacheKey sounds like you are fetching something from the cache. How about something like dedupKey

I'm not familiar with SwiftPM, but can target dependency be just a string (if no naming conflict)? Something like:

  dependencies: [
    "FlutterFramework",
  ]

Nit: I assume this refers to "Package.swift" file? How about hasSwiftPMManifest?

what does "fully compatible" mean? (and what is "partially" compatible? the ones without
"FlutterFramework" dependency?

I agree with @hellohuanlin. If we're going to keep them separate, let's move the common logic into a helper function

Or _validateExampleAppPluginSupportsSwiftPackageManager

I don't think this is needed

I'd move this logic into it's own method so it's clear what it's doing. For example, something like

Plugin? pluginFromExampleApp = _loadPluginFromExampleProject(...);

validationMessages does not need to be a List, it can just be a string since there is only ever one

Nothing out of this result is used except the validationMessages. Instead of returning a class, just return a String

I'd rather make this check overly generous rather than have potential false positives. Let's just check if the Package.swift contains the string FlutterFramework.