Flutter Package Development
Treat reusable packages as versioned contracts consumed by independent projects. Preserve SDK bounds, package architecture, supported platforms, and release conventions unless migration is requested.
Preflight
Inspect pubspec.yaml, public exports, examples, tests, platform folders, CI, changelogs, and consumers.
Choose the smallest viable shape:
- Dart package for reusable Dart-only logic.
- Flutter package for reusable widgets without native code.
- Plugin or FFI package when native platform implementations are required.
- Federated plugin only when independent platform ownership or release cadence justifies multiple packages.
Do not convert app-owned bridges into packages merely because code reuse is possible.
Load references conditionally
- Read public API and package quality for exports, deprecations, semver, and consumer compatibility.
- Read plugins and federation for platform interfaces, registration, FFI, and federated architecture.
- Read publication readiness for dry-run inspection, pub.dev checklist, and release verification.
Boundaries
flutter-platform-integration owns app-side native code and low-level channel/FFI mechanics.flutter-dependency-upgrades owns consumer-side package upgrades in an application.flutter-build-release owns application stores and binary builds, not pub package publication.
Verification
Format, analyze, run tests, and exercise the example fixture across all claimed platforms.
When publication readiness is in scope:
- Run
dart pub publish --dry-run and inspect all output, warnings, and included files. A passing dry run proves neither compatibility nor authorization.
- Never publish, tag, or create releases without explicit user authorization.
- When tool or repository access is missing, provide an executable review plan with clear pass/fail criteria covering metadata, license, changelog, and dry-run output rather than fabricating results.
Sources
1---2name: flutter-package-development3description: Create, evolve, test, or prepare reusable Dart packages and Flutter plugins for distribution. Use when the package itself, its public API, platform support, federation, example app, compatibility, or publication readiness is the deliverable; route app-owned native bridges to flutter-platform-integration.4---56# Flutter Package Development78Treat reusable packages as versioned contracts consumed by independent projects. Preserve SDK bounds, package architecture, supported platforms, and release conventions unless migration is requested.910## Preflight1112Inspect `pubspec.yaml`, public exports, examples, tests, platform folders, CI, changelogs, and consumers.13Choose the smallest viable shape:14- Dart package for reusable Dart-only logic.15- Flutter package for reusable widgets without native code.16- Plugin or FFI package when native platform implementations are required.17- Federated plugin only when independent platform ownership or release cadence justifies multiple packages.1819Do not convert app-owned bridges into packages merely because code reuse is possible.2021## Load references conditionally2223- Read [public API and package quality](references/public-api-and-quality.md) for exports, deprecations, semver, and consumer compatibility.24- Read [plugins and federation](references/plugins-and-federation.md) for platform interfaces, registration, FFI, and federated architecture.25- Read [publication readiness](references/publication-readiness.md) for dry-run inspection, pub.dev checklist, and release verification.2627## Boundaries2829- `flutter-platform-integration` owns app-side native code and low-level channel/FFI mechanics.30- `flutter-dependency-upgrades` owns consumer-side package upgrades in an application.31- `flutter-build-release` owns application stores and binary builds, not pub package publication.3233## Verification3435Format, analyze, run tests, and exercise the example fixture across all claimed platforms.36When publication readiness is in scope:37- Run `dart pub publish --dry-run` and inspect all output, warnings, and included files. A passing dry run proves neither compatibility nor authorization.38- Never publish, tag, or create releases without explicit user authorization.39- When tool or repository access is missing, provide an executable review plan with clear pass/fail criteria covering metadata, license, changelog, and dry-run output rather than fabricating results.4041## Sources4243- [Developing packages and plugins](https://docs.flutter.dev/packages-and-plugins/developing-packages)44- [Publishing packages](https://dart.dev/tools/pub/publishing)45- [Package layout conventions](https://dart.dev/tools/pub/package-layout)
thiennc-tesoglobal