Wyatt Packages
---
[[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_ --description A new Wyatt package --flutter_only false
```
Then bootstrap project with `melos bs` command.
#### Naming
In the previous instructions `` 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 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
melos run gen_coverage
```
#### 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 `nwyatt_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:

```markdown

```
or

```markdown

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

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