Flutter is Google's UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase. Flutter is used by developers and organizations around the world, and is free and open source.

Contribution

Clone this repo.

git clone ssh://git@git.wyatt-studio.fr:993/Wyatt-FOSS/wyatt-packages.git

Prerequisite

Flutter.
Melos. Used to manage Dart projects with multiple packages.

dart pub global activate melos

Mason. Used for code generation.

dart pub global activate mason_cli

Lcov. Used to generate coverage data.

# on macos
brew install lcov

genhtml. Used to convert coverage data into html pages.

After installing all these packages, bootstrap with melos bs.

Create a new package

Create a new package in packages/ folder.

mason make wyatt_package --package_name  wyatt_<name> --description A new Wyatt package --flutter_only false

Then bootstrap project with melos bs command.

Naming

In the previous instructions <name> variable is important. It have to be clear and intelligible.

You MUST use underscores.

You MUST use wyatt prefix for package.

You MUST name example with specific name.

For example, if name is CRUD BLOC

name will be crud_bloc
so the package will be: wyatt_crud_bloc
and the example will be: crud_bloc_example

Create issues

Add the issues directly related to what you want to develop and label them correctly.

Type(scope): issue.

For example, on notification bloc package :

Feature(notification_bloc): add firebase messaging data source.
Test(notification_bloc): add test for pushwoosh datasource.

Branches

Master is protected. You can't push on it. Please develop your feature on another branch. The name of your branch has to match with the issue opened.

type(scope):issue

Example : Issue :

Feature(notification_bloc): add firebase messaging data source.

Branch related to this issue :

feature(notification_bloc)/add_firebase_messaging_data_source

Commits

See Conventional Commits for commit guidelines.

tl;dr : type(scope): description #issue. Here allowed values:

feat for a new feature for the user, not a new feature for build script. Such commit will trigger a release bumping a MINOR version.
fix for a bug fix for the user, not a fix to a build script. Such commit will trigger a release bumping a PATCH version.
perf for performance improvements. Such commit will trigger a release bumping a PATCH version.
docs for changes to the documentation.
style for formatting changes, missing semicolons, etc.
refactor for refactoring production code, e.g. renaming a variable.
test for adding missing tests, refactoring tests; no production code change.
build for updating build configuration, development tools or other changes irrelevant to the user.

Some examples :

feat(auth): add AWS support. (#31) = add a feature in authentication_bloc package, linked to the 31st issue.
docs: update readme. = update this readme file.
fix(crud)!: fix bug in awesome() function. (#32) = fix a bug, ! is important and indicate BREAKING CHANGES linked with the 32nd issue.

When you have finished developing, and are ready to close the issue, close it via your commit :

feat(auth): add AWS support. (close #31)

Note that your issue will be close after merging on master. Before closing the issue, please check tests and update coverage. You might run :

melos run test:all # this will run all tests in this project
melos run gen-coverage # this will generate coverage report
melos run gen-class-models # this will generate plantuml class diagrams
melos run quality-check # this will run all targets generally expected in CI
melos run publish:validate # this will run a validation before publish packages
melos run publish # this will publish packages

Note that only modified package will be verified and published.

Merge your work

After closing your issue, some work may have been done on master in the meantime. To keep a clean git history, please rebase before opening a change request.

Two situations :

You have not yet created your branch and have committed locally :

git pull --rebase

You are already working on your branch :

git rebase -i master

If possible, please use --fixup on your commit in interactive rebase.

Then, opend your PR, get the necessary approval and merge your work. Then you're done ✅.

Update version.

Once your work is on the master, you can update your package version. Please filter packages to update only your package. --scope is used to do it. For example, after merging changes on wyatt_otification_bloc package, you might run :

melos version --scope="*wyatt_notification_bloc*"

In fact, melos will filter all packages that match the wyatt_notification_block pattern.

You can update check all packages tests by running :

melos run test

Publish your package

If package is ready for procution, publish it runnig :

melos publish --scope"*package*"

Badging

In the package readme.md file, please specify the supported SDK:

![SDK: Dart & Flutter](https://img.shields.io/badge/SDK-Dart%20%7C%20Flutter-blue?style=flat-square)

![SDK: Dart](https://img.shields.io/badge/SDK-Dart-blue?style=flat-square)

Usage

You can add any package of the packages/ sub directory in your project.

dependencies:
  wyatt_analysis:
    git:
      url: https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages
      ref: wyatt_analysis-v2.0.0
      path: packages/wyatt_analysis

Here you can change package name and package version.

Status

This repository is maintained by Wyatt Studio but work is in progress.

Simple work flow diagramm

To sum up, here a simple work flow diagramm.

Languages

Dart 97.5%

Shell 1%

HTML 0.9%

Ruby 0.2%

Swift 0.2%