<!--
 * Copyright (C) 2022 WYATT GROUP
 * Please see the AUTHORS file for details.
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org/licenses/>.
-->

<p align="center">

  <a href="https://wyattapp.io">
    <img width="150px" src="resources/wyatt-campus-logo.png">
  </a>
  <a href="https://wyatt-studio.fr">
    <img width="150px" src="resources/wyatt-studio-logo.png">
  </a>
  <h1 align="center">Wyatt Packages</h1>
</p>

<p align="center">
  <a href="https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages/src/branch/master/packages/wyatt_analysis">
    <img src="https://img.shields.io/badge/Style-Wyatt%20Analysis-blue.svg?style=flat-square" alt="Style: Wyatt Analysis" />
  </a>
  <a href="https://github.com/invertase/melos">
    <img src="https://img.shields.io/badge/Maintained%20with-melos-f700ff.svg?style=flat-square" alt="Maintained with Melos" />
  </a>
</p>

---

[[Changelog]](./CHANGELOG.md)

---

## About

Here is it a set of [Flutter plugins](https://flutter.io/platform-plugins/) that power up your applications.

[Flutter](https://flutter.dev) 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.

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

### Prerequisite

- [Flutter](https://github.com/flutter/flutter).

- [Melos](https://github.com/invertase/melos). Used to manage Dart projects with multiple packages.

```shell
dart pub global activate melos
```

- [Mason](https://github.com/felangel/mason). Used for code generation.

```shell
dart pub global activate mason_cli
```

- [Lcov](https://github.com/linux-test-project/lcov). Used to generate coverage data.

```shell
# 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.

```shell
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](https://conventionalcommits.org) for commit guidelines.

tl;dr : `type(scope): description #issue`.
Here allowed <type> 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 :

```shell
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 :

```shell
git pull --rebase
```

- You are already working on your branch :

```shell
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 :

```shell
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 :

```shell
melos run test
```

#### Publish your package

If package is ready for procution, publish it runnig :

```shell
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)

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

or

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

```markdown
![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.

```yaml
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

![Status: Experimental](https://img.shields.io/badge/Status-WIP-red?style=flat-square)

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.

![Dev Wokflow](doc/workflow.svg)
