Cleanup 5 year old handling of `pluginClass: none` #171922

matanlurey · 2025-07-09T22:08:38Z

Starting as a draft to get feedback - I am open to other options:

Adding a feature flag
Making none a toolExit(...)
Both of the above

stuartmorgan-g · 2025-07-10T12:12:26Z

Oops 😬 Looks like I forgot to set a reminder for step 2.

My 2-step plan didn't anticipate that a fair number of people would duplicate that entry into their plugins during the time we used it. Given that, I don't think we should just suddenly break it without warning.

As an updated plan I recommend we:

Add a warning now; something like:

The plugin 'foo' uses the deprecated 'pluginClass: none' it its pubspec.yaml, which will be a build error in future versions of Flutter and should be removed. Please contact the plugin's developers.
Set a reminder to remove all of this code one stable release later.

I'll also go file issues against all of the plugins in that query that don't appear to be abandoned.

I definitely don't think we should add a feature flag for this.

stuartmorgan-g · 2025-07-10T12:13:57Z

(Adjusted title; the thing we primarily supported and actually used was pluginClass: none to allow for plugins that only had a dartPluginClass. There was never a reason for someone to use dartPluginClass: none that I can think of.)

stuartmorgan-g · 2025-07-10T12:31:37Z

a fair number of people

Well, maybe not so many. Once I removed things that haven't been updated in a more than a year, projects that were apps that mysteriously added plugin entries with this key to the app pubspec (LLM hallucination?), third-party-embedding plugins, and local-to-project forks of old versions of plugins, I only have 5 repos left.

That said, I haven't done a full sweep of everything that's not on GitHub using https://github.com/loic-sharma/pub_insights/ yet, so there could be more. I still think one release of a warning is the safer option.

bkonyi

The conservative move would be to add a warning for at least one more release, but if we're fairly certain that this will impact a very small number of projects and pluginClass: none basically did nothing for years, I think the impact of just removing this now would be minimal. Could we just submit PRs to those few projects still setting this field and remove it?

bkonyi · 2025-07-10T18:32:46Z

packages/flutter_tools/test/general.shard/build_system/targets/dart_plugin_registrant_test.dart

+          languageVersions: <String, String>{'path_provider_example': '2.12'},
+        );
+
+        projectDir.childFile('pubspec.yaml').writeAsStringSync(_kSamplePubspecFile);


Ubernit: I'd probably just cascade these childFile and childDirectory calls off of projectDir.

stuartmorgan-g · 2025-07-10T20:22:29Z

and pluginClass: none basically did nothing for years

The issue isn't that it did nothing, it's that removing the special casing for it will change the behavior from "do nothing" to "fail at build time with a hard-to-understand error".

Could we just submit PRs to those few projects still setting this field and remove it?

I filed issues with the ones I found with GitHub. We could do a second pass with the insights tool to find anything published on pub.dev that doesn't use GitHub that has this issue.

But an unknowable (probably small, but we by definition can't know) number of projects use non-published plugins that have this issue. And an unknown number of projects still use old versions of plugins (including ours, potentially) that still have the entry even if was removed.

bkonyi · 2025-07-10T20:40:16Z

Fair enough. Let's just provide a warning for a single stable release and then remove this workaround for the next stable.

matanlurey · 2025-07-17T21:00:56Z

Replaced by #172315.

@stuartmorgan-g

Towards #57497. Supersedes #171922 based on @stuartmorgan-g's advice for a warning release. I'll CP this into `3.35` (beta) so that we can clean it up on `master` anytime.

@stuartmorgan-g