Document ffiPlugin pubspec.yaml key, and its implications on existing plugins that use FFI

[Piero512]

Hello!

I would like the documentation to be able to answer this following questions.

• What is this new ffiPlugin key in the pubspec.yaml and what does it do?
• Plugins using FFI existed before this pubspec.yaml key was introduced, so what changes under the hood?
• Can we keep the unused method channel so that our plugin keeps building on older versions of flutter?
• when was that key in the pubspec.yaml introduced?

Also, for extra consideration, can you maybe reply this questions (they're not completely required)

• Will you use it for PANA?
• Do you tree shake the native implementation if the dart library is never used?
• Do you link statically and reflect on the FFI annotations to tell the linker to drop unused references?

[dcharkes]

Hello!

Hi!

I would like the documentation to be able to answer this following questions.

Where in the documentation would you like these questions answered?

• What is this new ffiPlugin key in the pubspec.yaml and what does it do?

It ensures native libraries are build and bundles (similar to non-FFI plugins) but does not include method channel boilerplate.

• Plugins using FFI existed before this pubspec.yaml key was introduced, so what changes under the hood?

These plugins included method channel boilerplate that would make the build fail if deleted.

Moreover, users had to figure out how to build/bundle native code for each target platform manually.

Use flutter create --template=plugin_ffi --platfrom=... to get an FFI plugin that has some sample C code for which the building and bundling works out of the box.

• Can we keep the unused method channel so that our plugin keeps building on older versions of flutter?

Yes, you can keep using --template plugin and plugin: instead of ffiPlugin:. The bundling logic for native libraries is identical. The --template plugin does not include sample C code, so you might want to copy that and the buildfiles over from --template plugin_ffi.

• when was that key in the pubspec.yaml introduced?

• FFI plugins #96225

Also, for extra consideration, can you maybe reply this questions (they're not completely required)

• Will you use it for PANA?

cc @jonasfj

• Do you tree shake the native implementation if the dart library is never used?

This is work in progress.

• Do you link statically and reflect on the FFI annotations to tell the linker to drop unused references?

This is work in progress with @FfiNative annotations.

[Piero512]

Woah, that was a speedy response, thank you!.

Honestly, now with those questions answered, I would think that maybe a slight paragraph with the changes for those "unofficial" plugins would have helped it going a long way. Something the likes of

we know that developers have coerced the flutter build system to bundle native code only to use it through dart:ffi and you don't need to migrate your code to the new ffiplugins just yet. You can now drop the unused method channel, or if you're still targeting older versions of flutter, keep it.

[dcharkes]

cc @RedBrogdon

[stuartmorgan]

Where in the documentation would you like these questions answered?

https://docs.flutter.dev/development/packages-and-plugins/developing-packages would be the best place to document the new key; in a section similar to the recently-added https://docs.flutter.dev/development/packages-and-plugins/developing-packages#dart-platform-implementations

(From a docs standpoint, the answer to the question of when it was introduced is "3.0".)