See also: Flutter's code of conduct
We welcome all contributions to the project, however some contributions will need extra work in order to be accepted.
Here's some examples:
We need to make sure it works well before merging and each platform needs to be reviewed individually.
Ideally an expert in that platform will have to review the change to make sure it works as expected.
New features should cover at least the mobile platforms (Android and iOS) to be considered, and a plan for the rest must be provided.
We don't have the capacity to accept new plugins.
Please follow this steps when working on the PlusPlugins.
flutter_plugin_tools
locally activated.tuneup
locally activated.https://github.com/fluttercommunity/plus_plugins
into your own GitHub account. If
you already have a fork, and are now installing a development environment on
a new machine, make sure you've updated your fork so that you don't use stale
configuration options from long ago.git clone git@github.com:<your_name_here>/plus_plugins.git
git remote add upstream git@github.com:fluttercommunity/plus_plugins.git
(So that you
fetch from the master repository, not your clone, when running git fetch
et al.)PlusPlugins uses Melos to manage the project and dependencies.
To install Melos, run the following command from your SSH client:
flutter pub global activate melos
Next, at the root of your locally cloned repository bootstrap the projects dependencies:
melos bootstrap
The bootstrap command locally links all dependencies within the project without having to
provide manual dependency_overrides
. This allows all
plugins, examples and tests to build from the local clone project.
You do not need to run
flutter pub get
once bootstrap has been completed.
Each plugin provides an example app which aims to showcase the main use-cases of each plugin.
To run an example, run the flutter run
command from the example
directory of each plugins main
directory. For example, for sensors_plus
example:
cd packages/sensors_plus/sensors_plus/example
flutter run
Using Melos (installed in step 3), any changes made to the plugins locally will also be reflected within all example applications code automatically.
PlusPlugins comprises of a number of tests for each plugin, either end-to-end (e2e) or unit tests.
Unit tests are responsible for ensuring expected behavior whilst developing the plugins Dart code. Unit tests do not
interact with 3rd party services, and mock where possible. To run unit tests for a specific plugin, run the
flutter test
command from the plugins root directory. For example, sensors_plus platform interface tests can be run
with the following commands:
cd packages/sensors_plus/sensors_plus
flutter test
E2e tests are those which directly communicate with Flutter, whose results cannot be mocked. These tests run directly from an example application.
To run e2e tests, run the flutter test
command from the plugins main example
directory, and provide the path to the
e2e test file. For example, to run the sensors_plus
e2e tests:
cd packages/sensors_plus/sensors_plus/example
flutter test integration_test/sensors_plus_test.dart
To run tests against web environments, you will need to have Chrome and ChromeDriver installed and use the flutter drive
command.
First start ChromeDriver on port 4444:
chromedriver --port=4444
Then go to the example
directory of the plugin you want to test and run the flutter drive
command
with the specific driver and *_web_test.dart
target. For example, to run the package_info_plus
web tests:
cd packages/package_info_plus/package_info_plus/example
flutter drive \
--driver ./integration_test/driver.dart \
--target ./integration_test/package_info_plus_web_test.dart \
-d chrome
To help aid developer workflow, Melos provides a number of commands to quickly run tests against plugins. For example, to run all e2e tests across all plugins at once, run the following command from the root of your cloned repository:
# for mobile testing (Android or iOS)
melos run test:mobile_e2e
A full list of all commands can be found within the melos.yaml
file.
We gladly accept contributions via GitHub pull requests.
Please peruse the Flutter style guide and design principles before working on anything non-trivial. These guidelines are intended to keep the code consistent and avoid common pitfalls.
To start working on a patch:
git fetch upstream
git checkout upstream/main -b <name_of_your_branch>
Once you have made your changes, ensure that it passes the internal analyzer & formatting checks. The following commands can be run locally to highlight any issues before committing your code:
# Run the analyze check
melos run analyze
# Format code
melos run format
NEW: Do not modify the CHANGELOG.md or the version in the pubspec.yaml, this is handled by the maintainers from now on
Assuming all is successful, commit and push your code:
git commit -a -m "<your informative commit message>"
git push origin <name_of_your_branch>
To send us a pull request:
git pull-request
(if you are using Hub) or
go to https://github.com/fluttercommunity/plus_plugins
and click the
"Compare & pull request" buttonPlease make sure all your check-ins have detailed commit messages explaining the patch.
When naming the title of your pull request, please follow the Conventional Commits
guide. For example, for a fix to the sensor_plus
plugin:
fix(sensor_plus): fixed a bug!
Please also enable “Allow edits by maintainers”, this will help to speed-up the review process as well.
Plugins tests are run automatically on contributions using GitHub Actions. Depending on your code contributions, various tests will be run against your updated code automatically.
Once you've gotten an LGTM from a project maintainer and once your PR has received the green light from all our automated testing, wait for one the package maintainers to merge the pull request.
Please understand, that this repository is run by volunteers, and the response may be delayed.
Newly opened PRs first go through initial triage which results in one of:
We push releases manually, using Melos to take care of the hard work.
Some things to keep in mind before publishing the release:
main
branch locally.git pull origin main
.git pull --tags
to make sure all tags are fetched.release/[year]-[month]-[day]
.melos version --no-git-tag-version
to automatically version packages and update Changelogs.melos publish
to dry run and confirm all packages are publishable.git push origin [RELEASE BRANCH NAME]
& open pull request for review on GitHub.git pull origin main
.melos publish --no-dry-run --git-tag-version
to now publish to Pub.dev.git push --tags
to push tags to repository.此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。