Update ecosystem contribution docs (#157288)

Document the requirements for adding a new external, client-facing dependency in flutter/packages
This commit is contained in:
stuartmorgan
2024-10-21 12:06:04 -07:00
committed by GitHub
parent 6cae408579
commit e0d6271911

View File

@@ -114,7 +114,7 @@ Because we prefer to minimize breaking changes to packages after 1.0, breaking c
## Dependencies
We try to minimize external package dependencies as much as possible, where "external" means packages that are not generally within the control of the Flutter or Dart teams (Examples non-external packages include `sdk:` dependencies, packages in flutter/packages, and packages published by dart.dev), or by an organization with a track record of strong support for both engineering best practices and Flutter. This is for several reasons:
We try to minimize external package dependencies as much as possible, where "external" means packages that are not generally within the control of the Flutter or Dart teams (Examples of non-external packages include `sdk:` dependencies, packages in flutter/packages, and packages published by dart.dev), or by an organization with a track record of strong support for both engineering best practices and Flutter. This is for several reasons:
- Maintainability:
- We have a policy of always supporting Flutter `master`; if we can't guarantee that fixes for breaking changes can be landed immediately in dependencies, it can block our roller.
- If a package is abandoned by its authors, we will have to fork or migrate in order to unblock the entire repository.
@@ -125,12 +125,21 @@ If you are considering adding an external dependency:
- Consider other options, and discuss with #hackers-ecosystem in Discord.
- If you add a `dev_dependency` on an external package, pin it to a specific version if at all possible.
- If you add a `dependency` on an external package in an `example/`, pin it to a specific version if at all possible.
- Some dependencies should only be linked as dev_dependencies like integration_test
- If you add a non-dev, non-example dependency on an external package, a formal approval is required, and all of the following must be true:
- The dependency is necessary for a high-priority product/feature.
- The code has an OSS license, and the original source repository is available.
- The dependency has an exact upper bound set to a version that has been reviewed by the Flutter team
- The ecosystem TL and PM are confident that the code could be forked and maintained by the Flutter team if it were to become necessary (e.g., if the package were later abandoned).
### Native dependencies
The same general principles apply to native dependencies for plugins (e.g., dependencies specified in an Android Gradle file or iOS podspec file): minimize dependencies—and especially non-test dependencies—on libraries that are not created by either the platform vendor or another organization with a track record of strong support for engineering best practices in whom we can have a very high degree of confidence in ongoing support and prompt updates.
### Dev dependencies
Some dependencies should only be linked as dev_dependencies, such as `integration_test`. Known dev-only dependencies are checked by CI, and if you are adding a new dev-only dependency, consider adding it to
[the repository tooling checks](https://github.com/flutter/packages/blob/main/script/tool/lib/src/pubspec_check_command.dart).
## Platform Support
The goal is to have any plugin feature work on every platform on which that feature makes sense; having a lot of features that are only partially implemented across platforms is often confusing and frustrating for developers trying to use those plugins. However, a single developer will not always have the expertise to implement a feature across all supported platforms.