273 lines
9.0 KiB
Markdown
273 lines
9.0 KiB
Markdown
<!--
|
|
* 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://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 a set of [Flutter plugins](https://flutter.io/platform-plugins/) that enhance your applications.
|
|
|
|
[Flutter](https://flutter.dev) is Google's UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop using a single codebase. It is used by developers and organizations worldwide 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
|
|
|
|
1. [Flutter](https://github.com/flutter/flutter). It is a UI toolkit developed by Google for building beautiful and natively compiled applications for mobile, web, and desktop from a single codebase.
|
|
|
|
2. [Melos](https://github.com/invertase/melos). Melos is a tool that helps in managing Dart projects that have multiple packages. It can be installed using the following command:
|
|
|
|
```shell
|
|
dart pub global activate melos
|
|
```
|
|
|
|
3. [Mason](https://github.com/felangel/mason). Mason is used for code generation purposes. It can be installed by running the following command:
|
|
|
|
```shell
|
|
dart pub global activate mason_cli
|
|
```
|
|
|
|
4. [Lcov](https://github.com/linux-test-project/lcov). Lcov is a tool used to generate coverage data. It can be installed on macOS by running the following command:
|
|
|
|
```shell
|
|
# on macos
|
|
brew install lcov
|
|
```
|
|
|
|
- genhtml. Used to convert coverage data into html pages.
|
|
|
|
After installation of all these packages, the project can be bootstrapped using the command `melos bs`.
|
|
|
|
### Create a new package
|
|
|
|
Create a new package in `packages/` folder.
|
|
To create a new package in the packages/ folder, run the following command in the terminal:
|
|
|
|
```shell
|
|
mason make wyatt_package --package_name wyatt_<name> --description A new Wyatt package --flutter_only false
|
|
```
|
|
|
|
The <name> variable in the above command is important and must be clear and understandable.
|
|
|
|
After creating the package, bootstrap the project with the `melos bs` command.
|
|
|
|
#### Naming
|
|
|
|
In the previous instructions `<name>` variable is important.
|
|
It have to be clear and intelligible.
|
|
|
|
1. You must use underscores in the name.
|
|
2. You must use the wyatt prefix for the package name.
|
|
3. You must name the example with a specific name.
|
|
|
|
For example, if the name is "CRUD BLOC," the following naming conventions should be used:
|
|
|
|
1. name: crud_bloc
|
|
2. package name: wyatt_crud_bloc
|
|
3. example name: crud_bloc_example
|
|
|
|
### Create issues
|
|
|
|
Create an issue for each specific feature or task you want to work on and label it correctly using the following format:
|
|
|
|
```
|
|
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
|
|
|
|
The master branch is protected and cannot be pushed to directly. Please create a separate branch for each feature or task, with a name that corresponds to the related issue. The branch name should follow this format:
|
|
|
|
`type(scope):issue`
|
|
|
|
Example :
|
|
For the issue:
|
|
|
|
- `Feature(notification_bloc): add firebase messaging data source.`
|
|
|
|
The related branch should be named:
|
|
|
|
- `notification_bloc/feat/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 completed your development work and are ready to resolve the related issue, you can close it via your commit message by including (close #issue_number). For example:
|
|
|
|
```shell
|
|
feat(auth): add AWS support. (close #31)
|
|
```
|
|
|
|
```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
|
|
```
|
|
|
|
Please note that the issue will only be closed after it has been merged into the master branch. Before closing the issue, it is important to verify that all tests have been run and that coverage has been updated.
|
|
|
|
#### Merge your work
|
|
|
|
When you have completed your work and closed the related issue, it's possible that some changes may have been made to the master branch in the meantime. To maintain a clean Git history, it's recommended to rebase before creating a change request (pull request).
|
|
|
|
Two situations :
|
|
|
|
- You haven't created a branch yet and have made local commits:
|
|
|
|
```shell
|
|
git pull --rebase
|
|
```
|
|
|
|
- You are already working on a branch:
|
|
|
|
```shell
|
|
git rebase -i master
|
|
```
|
|
|
|
It's recommended to use the `--fixup` option during the interactive rebase to keep the Git history clean.
|
|
|
|
Once you have rebased, you can create a pull request, receive the necessary approvals, and then merge your work. And with that, you're done! 🎉
|
|
|
|
#### Update version.
|
|
|
|
When your work has been merged into the master branch, it's time to update the package version. To update only your specific package, use the --scope option. For example, after merging changes into the `wyatt_notification_bloc` package, you can run the following command:
|
|
|
|
```shell
|
|
melos version --scope="*wyatt_notification_bloc*"
|
|
```
|
|
|
|
This will filter all packages that match the `wyatt_notification_bloc` pattern and update only that package.
|
|
|
|
You can then verify that all packages and their tests are working correctly by running:
|
|
|
|
```shell
|
|
melos run test:all
|
|
```
|
|
|
|
#### 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`.
|
|
|
|
---
|
|
|
|
## Simple work flow diagramm
|
|
|
|
To sum up, here a simple work flow diagramm.
|
|
|
|
|
|
|
|
## Status
|
|
|
|
|
|
|
|
This repository is maintained by Wyatt Studio but work is in progress.
|