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

• Developing packages and plugins
• Publishing packages
• Package layout conventions