Skip to content

Latest commit

 

History

History
72 lines (57 loc) · 3.81 KB

CONTRIBUTING.md

File metadata and controls

72 lines (57 loc) · 3.81 KB
Raw

Contributing

Setup

This project uses an assortment of tools for the development. Currently included are:

  • fvm for managing Flutter versions
  • melos for managing packages in this monorepo
  • commitlint_cli for validating commits according to the conventional commits specification

To set up all these tools run the ./tool/setup.sh script. Note that you need to have Dart installed and ~/.pub-cache/bin/ needs to be in your PATH before running the script.

You will need to have the following dependencies installed to get the app running:

For working with lower levels like generating the OpenAPI specifications a few more dependencies are required:

  • jsonpatch
  • PHP
  • composer Make sure to initialize the git submodules by running git submodule update --init --recursive. This will add our external dependencies to external/ so scripts can use them for generation.

For running a development Nextcloud instance:

Picking an issue

You may wish to start with our list of good first issues

Commits

All commits need to be signed and signed off to pass our tests. To sign off your commits use git commit --signoff. To setup commit signing please consult the Github documentation. We use conventional commits to have meaningful commit messages and be able to generate changelogs. A non-breaking feature contribution to notes_app could look like this:

git commit -m "feat(notes_app): Add a super cool feature."

You can read the full documentation at https://www.conventionalcommits.org.

Tools

We maintain a collection of scripts in ./tool/. They range from setting up a local Nextcloud server (./tool/dev.sh) to generating assets.

Monorepo

For easier development we use a monorepo structure. This means that we have multiple packages in one git repository. We use melos to manage the packages in this repository.

Take a look at our melos.yaml to find useful commands for running commands like build_runner or the analyzer in all packages.

Linting

We use very strict static code analysis (also known as linting) rules. This enables us to maintain and verify a consistent code style throughout the repository. Please make sure your code passes linting.

You can read more about it on dart.dev.

Testing

If you found a bug and are here to fix it, please make sure to also submit a test that validates that the bug is fixed. This way we can make sure it will not be introduced again.

Documentation

Whenever you are submitting new features make sure to also add documentation comments in the code. Please adhere to the effective-dart documentation guidelines.

Workflow

We use a rebase workflow, meaning that we rebase PRs onto the latest main branch instead of merging the current main into the development branches. This helps to keep the git history cleaner and easier to bisect in the case of debugging an error. You can read more on it here.