The plugin is ignored by registrant after Flutter 3.27

[AlexV525]

See flutter/flutter#160143.

The workaround is adding the dependency to the app project.

[stuartmorgan-g]

As noted in the flutterr/flutter issue, this registration system was relying on a bug in Flutter that was fixed in 3.27. Previously Flutter would build and register all native implementations of a plugin that were present in the transitive dependency tree. Now it (as originally intended, as documented in the initial design document) will only include the native implementation that fits the selection criteria.

The right way for an application using video_player to select an alternate implementation is to depend directly on that player in its pubspec.yaml, rather than to manually call registration code.

Which raises a potentially related question: why does this plugin depend on video_player? Having an implementation of a plugin depend on the app-facing package of the plugin isn't an intended part of the federated plugin design.

[wang-bin]

Which raises a potentially related question: why does this plugin depend on video_player? Having an implementation of a plugin depend on the app-facing package of the plugin isn't an intended part of the federated plugin design.

Because the plugin also provides an extension of VideoPlayerController.

[wang-bin]

what about moving controller.dart to a new package and remove video_player from dependencies?

[AlexV525]

That would be no help with the current circumstances. The remaining thing we probably do is add a notice that the dependency must be declared in the app projects.

[wang-bin]

That would be no help with the current circumstances. The remaining thing we probably do is add a notice that the dependency must be declared in the app projects.

so other plugins have the same problem?

[stuartmorgan-g]

so other plugins have the same problem?

I'm not aware of any other plugins that aggregated a set of possible overrides of another plugin's implementations into a single meta-plugin using a Dart-based registration scheme to select which ones to use on a per-platform basis at runtime. That is what no longer works.

You have several options that I can see:

1. You could keep the current plugin structure, but remove the API that is intended to allow opting in. Clients would either depend directly on fvp, in which case they would get the fvp implementation on all platforms (and not build the native portions of the video_player_* default implementations), or they would get none of them.

2. You could split it apart into one plugin per platform. Clients would depend directly on whichever overrides they wanted.

3. You could split into two plugins:

   • One would be a plugin containing all of the implementations, and would not declare itself as implementing video_player in pubspec.yaml.
   • One would contain the client-facing Dart code, including the registration system, and no native code, and declare itself as a video_player implementation.

   This structure should allow you to keep all of the same behaviors as you had before—with the same primary drawback, which is that clients are shipping the native code for two implementations of video_player but only using one of them.