Contributing to FlutterFire
See also: Flutter's code of conduct
Things you will need
- Linux, Mac OS X, or Windows.
- git (used for source version control).
- An ssh client (used to authenticate with GitHub).
Getting the code and configuring your environment
- Ensure all the dependencies described in the previous section are installed.
https://github.com/FirebaseExtended/flutterfireinto 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.
- If you haven't configured your machine with an SSH key that's known to github, then follow GitHub's directions to generate an SSH key.
git clone firstname.lastname@example.org:<your_name_here>/flutterfire.git
git remote add upstream email@example.com:FirebaseExtended/flutterfire.git(So that you fetch from the master repository, not your clone, when running
git fetchet al.)
Running the examples
To run an example with a prebuilt binary from the cloud, switch to that
example's directory, run
pub get to make sure its dependencies have been
downloaded, and use
flutter run. Make sure you have a device connected over
USB and debugging enabled on that device.
Running the tests
Flutter plugins have both unit tests of their Dart API and integration tests that run on a virtual or actual device.
To run the unit tests:
flutter test test/<name_of_plugin>_test.dart
To run the integration tests:
cd example flutter drive test/<name_of_plugin>.dart
We gladly accept contributions via GitHub pull requests.
To start working on a patch:
git fetch upstream
git checkout upstream/master -b <name_of_your_branch>
- Hack away.
- Verify changes with flutter_plugin_tools
pub global activate flutter_plugin_tools pub global run flutter_plugin_tools format --plugins plugin_name pub global run flutter_plugin_tools analyze --plugins plugin_name pub global run flutter_plugin_tools test --plugins plugin_name
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/FirebaseExtended/flutterfireand click the "Compare & pull request" button
Please make sure all your checkins have detailed commit messages explaining the patch.
For pull requests that affect only one Flutterfire plugin, use a title that starts with the name of the plugin in brackets (e.g. [cloud_firestore]).
Plugins tests are run automatically on contributions using Cirrus CI. However, due to cost constraints, pull requests from non-committers may not run all the tests automatically.
The plugins team prefers that unit tests are written using
rather than using mockito to mock out
MethodChannel. For a list of the plugins that
are still using the mockito testing style and need to be converted, see
issue 34284. If you are contributing
tests to an existing plugin that uses mockito
MethodChannel, consider converting
them to use
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 and
pub submit any affected packages.
You must complete the Contributor License Agreement. You can do this online, and it only takes a minute. If you've never submitted code before, you must add your (or your organization's) name and contact info to the AUTHORS file.
The review process
- This is a new process we are currently experimenting with, feedback on the process is welcomed at the Gitter contributors channel. *
Reviewing PRs often requires a non trivial amount of time. We prioritize issues, not PRs, so that we use our maintainers' time in the most impactful way. Issues pertaining to this repository are managed in the flutter/flutter issue tracker and are labeled with "plugin". Non trivial PRs should have an associated issue that will be used for prioritization. See the prioritization section in the Flutter wiki to understand how issues are prioritized.
Newly opened PRs first go through initial triage which results in one of:
- Merging the PR - if the PR can be quickly reviewed and looks good.
- Closing the PR - if the PR maintainer decides that the PR should not be merged.
- Moving the PR to the backlog - if the review requires non trivial effort and the issue isn't a priority; in this case the maintainer will:
- Make sure that the PR has an associated issue labeled with "plugin".
- Add the "backlog" label to the issue.
- Leave a comment on the PR explaining that the review is not trivial and that the issue will be looked at according to priority order.
- Starting a non trivial review - if the review requires non trivial effort and the issue is a priority; in this case the maintainer will:
- Add the "in review" label to the issue.
- Self assign the PR.