On 1.18 (current master), desktop plugins can either specify a pluginClass for a standard plugin with native code, or a dartPluginClass to allow that platform's implementation of a plugin to be Dart-only. However, the current stable build, 1.17, doesn't have this logic, and requires a pluginClass for all desktop platforms. When building for any platform, all platforms listed in the pubspec are validated, which means that publishing a plugin with:

  plugin:
    platforms:
        dartPluginClass: Foo

will break the iOS and Android builds of any project that ends up with a dependency on that plugin. That means that for example we can't publish a Dart-only Linux implementation of path_provider and endorse it without breaking everyone on stable.

To work around this, I propose temporarily adding special handling to the desktop platforms where having pluginClass: none is treated the same way as having no pluginClass field. This will pass validation on 1.17, but be a no-op on master. The workaround would be removed once 1.18 is released to stable.

Minor downsides:

• Desktop builds with older versions of master will break when using one of these plugins. It's master though, so it's reasonable to say that you need to be using the latest version if you want to use published plugins on desktop.
• If someone is building on desktop using another channel and bypassing our check (e.g., changing to a local branch at the same revision but a different name) they will break when using one of these plugins. However, that's not a supported configuration, so I'm fine with that tradeoff. Someone who really wants to do this can always patch their local copy with the workaround, or pin to a version of the plugin that doesn't endorse a plugin using this.