Skip to content

Latest commit

 

History

History
54 lines (32 loc) · 3.92 KB

CONTRIBUTING.md

File metadata and controls

54 lines (32 loc) · 3.92 KB
Raw

Contributing

We want this community to be friendly and respectful to each other. Please follow it in all your interactions with the project.

Development workflow

This project is made up of hand-written and generated code. Code generation is performed using both the json_serializable package (for serialisation/deserialisation of JSON messages) and the pigeon package (for typesafe communication with native plugins). Both of these generation packages follow the same approach:

  • update the model
  • run the corresponding script to generate the code

For any change, the easiest way to test your change is to update the example app (found under the example folder) and build and run that.

JSON Code Generation

For the core package, the JSON models are defined in two locations event.dart and state.dart. The corresponding generated code is found in the similarly named .g.dart file (event.g.dart and state.g.dart, respectively). Several of the plugins also contain JSON models (for example properties.dart for the Firebase plugin), and can be identified by looking for a corresponding .g.dart file.

In each case, if such a model file is updated, the script to run can be found in the root of the package folder and is called build_json_models.sh (so, for example, under the core package, you'll find it here).

Pigeon Code Generation

Thre core package and several of the plugins define Pigeon models for typesafe communication with their native implementations. These models will always be found under the pigeon folder of each package folder (so, for example, under the core package, you'll find it here).

In each case, if such a model file is updated, the script to run can be found in the root of the package folder and is called build_pigeon_plugins.sh (so, for example, under the core package, you'll find it here).

Commit message convention

We follow the conventional commits specification for our commit messages:

  • fix: bug fixes, e.g. fix crash due to deprecated method.
  • feat: new features, e.g. add new method to the module.
  • refactor: code refactor, e.g. migrate from class components to hooks.
  • docs: changes into documentation, e.g. add usage example for the module..
  • test: adding or updating tests, eg add integration tests using detox.
  • chore: tooling changes, e.g. change CI config.

Our pre-commit hooks verify that your commit message matches this format when committing.

Linting and tests

Tests for the various packages can be found under the test folder of each package folder. The core tests use (Mockito)[https://pub.dev/packages/mockito] package for generating code for mocks for easy testing. This can be found under the mocks folder. If this file is updated, the mock code can be regenerated by running the json generation script.

Sending a pull request

Working on your first pull request? You can learn how from this free series: How to Contribute to an Open Source Project on GitHub.

When you're sending a pull request:

  • Prefer small pull requests focused on one change.
  • Verify that linters and tests are passing.
  • Review the documentation to make sure it looks good.
  • Follow the pull request template when opening a pull request.
  • For pull requests that change the API or implementation, discuss with maintainers first by opening an issue.