Wyatt-FOSS/wyatt-packages
Wyatt-FOSS/wyatt-packages
6
2
Fork 0
Code Issues 20 Pull Requests 3 Actions Packages Projects Releases Activity

master #81

Closed
malo wants to merge 322 commits from master into feat/bloc_layout/new-package
pull from: master
merge into: Wyatt-FOSS:feat/bloc_layout/new-package
Conversation 0 Commits 322 Files Changed 1069 +114 -102
3 changed files with 114 additions and 102 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 973eefa7bc - Show all commits

170
README.md
View File

@ -1,5 +1,5 @@
<!-- <!--
* Copyright (C) 2022 WYATT GROUP * Copyright (C) 2023 WYATT GROUP
* Please see the AUTHORS file for details. * Please see the AUTHORS file for details.
* *
* This program is free software: you can redistribute it and/or modify * This program is free software: you can redistribute it and/or modify
@ -17,19 +17,13 @@
--> -->
<p align="center"> <p align="center">
<a href="https://wyatt-studio.fr"> <a href="https://wyatt-studio.fr"><img width="150px" src="resources/wyatt-studio-logo.png"></a>
<img width="150px" src="resources/wyatt-studio-logo.png">
</a>
<h1 align="center">Wyatt Packages</h1> <h1 align="center">Wyatt Packages</h1>
</p> </p>
<p align="center"> <p align="center">
<a href="https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages/src/branch/master/packages/wyatt_analysis"> <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>
<img src="https://img.shields.io/badge/Style-Wyatt%20Analysis-blue.svg?style=flat-square" alt="Style: Wyatt Analysis" /> <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>
</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> </p>
--- ---
@ -38,12 +32,40 @@
--- ---
<!-- @import "[TOC]" {cmd="toc" depthFrom=1 depthTo=6 orderedList=false} -->
<!-- code_chunk_output -->
- [About](#about)
- [Contribution](#contribution)
- [Prerequisite](#prerequisite)
- [Create a new package](#create-a-new-package)
- [Naming](#naming)
- [Create issues](#create-issues)
- [Branches](#branches)
- [Commits](#commits)
- [Before pushing](#before-pushing)
- [Merge your work](#merge-your-work)
- [Update version.](#update-version)
- [Publish your package](#publish-your-package)
- [Badging](#badging)
- [Usage](#usage)
- [Simple work flow diagramm](#simple-work-flow-diagramm)
- [Status](#status)
- [License](#license)
<!-- /code_chunk_output -->
---
## About ## About
Here is a set of [Flutter plugins](https://flutter.io/platform-plugins/) that enhance your applications. 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. [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.
Those packages are developed by [Wyatt Studio](https://wyatt-studio.fr) and are available exclusively on this repository.
--- ---
## Contribution ## Contribution
@ -77,7 +99,7 @@ dart pub global activate mason_cli
brew install lcov brew install lcov
``` ```
- genhtml. Used to convert coverage data into html pages. * 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` . After installation of all these packages, the project can be bootstrapped using the command `melos bs` .
@ -87,9 +109,11 @@ Create a new package in `packages/` folder.
To create a new package in the packages/ folder, run the following command in the terminal: To create a new package in the packages/ folder, run the following command in the terminal:
```shell ```shell
mason make wyatt_package --package_name wyatt_<name> --description A new Wyatt package --flutter_only false mason make wyatt_package_template --package_name <name> --description A new Wyatt package --flutter false
``` ```
> Browse our [bricks](https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-bricks) for more information.
The <name> variable in the above command is important and must be clear and understandable. 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. After creating the package, bootstrap the project with the `melos bs` command.
@ -101,70 +125,63 @@ It have to be clear and intelligible.
1. You must use underscores in the name. 1. You must use underscores in the name.
2. You must use the wyatt prefix for the package 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: For example, if the name is `CRUD BLOC` the following naming conventions should be used:
1. name: crud_bloc 1. package name: `wyatt_crud_bloc`
2. package name: wyatt_crud_bloc 2. example name: `example`
3. example name: crud_bloc_example
### Create issues ### Create issues
Create an issue for each specific feature or task you want to work on and label it correctly using the following format: Create an issue for each specific feature or task you want to work on and label it correctly using the following labels: https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages/labels.
``` For example, if you want to work on the `i18n` package, you should create an issue with the `i18n` label.
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 ### 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: 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` `scope/type/short-name`
Example : For example, if you are working on the `i18n` package and you want to add a new feature, you should create a branch named `i18n/feat/add-new-feature` .
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 ### Commits
See [Conventional Commits](https://conventionalcommits.org) for commit guidelines. See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
tl;dr : `type(scope): description #issue`. tldr : `type(scope): description #issue` .
Here allowed <type> values: 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. * **build** for updating build configuration, development tools or other changes irrelevant to the user.
- **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. * **ci** for changes to our CI configuration files and scripts.
- **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version. * **docs** for changes to documentation.
- **docs** for changes to the documentation. * **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.
- **style** for formatting changes, missing semicolons, etc. * **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.
- **refactor** for refactoring production code, e.g. renaming a variable. * **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version.
- **test** for adding missing tests, refactoring tests; no production code change. * **refactor** for refactoring production code, e.g. renaming a variable.
- **build** for updating build configuration, development tools or other changes irrelevant to the user. * **style** for formatting changes, missing semicolons, etc.
* **test** for adding missing tests, refactoring tests; no production code change.
* **chore** for updating grunt tasks etc; no production code change.
> Check `.pre-commit-config.yaml` and [pre-commit](https://pre-commit.com/) for more information about commit hooks.
Some examples : Some examples :
- `feat(auth): add AWS support. (#31)` = add a feature in authentication_bloc package, linked to the 31st issue. * `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. * `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. * `fix(crud)!: fix bug in awesome() function. (closes #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: 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 (closes #issue_number). For example:
```shell ```shell
feat(auth): add AWS support. (close #31) feat(auth): add AWS support. (closes #31)
``` ```
> You can use `close` , `closes` , `closed` , `fix` , `fixes` , `fixed` , `resolve` , `resolves` or `resolved` .
#### Before pushing
```shell ```shell
melos run test:all # this will run all tests in this project melos run test:all # this will run all tests in this project
melos run gen-coverage # this will generate coverage report melos run gen-coverage # this will generate coverage report
@ -176,19 +193,19 @@ 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. 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 ### 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). 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 : Two situations :
- You haven't created a branch yet and have made local commits: * You haven't created a branch yet and have made local commits:
```shell ```shell
git pull --rebase git pull --rebase
``` ```
- You are already working on a branch: * You are already working on a branch:
```shell ```shell
git rebase -i master git rebase -i master
@ -198,7 +215,7 @@ It's recommended to use the `--fixup` option during the interactive rebase to ke
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! 🎉 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. ### 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: 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:
@ -214,22 +231,24 @@ You can then verify that all packages and their tests are working correctly by r
melos run test:all melos run test:all
``` ```
#### Publish your package ### Publish your package
If package is ready for procution, publish it runnig : If package is ready for production, publish it by running the following command :
```shell ```shell
melos publish --scope"*package*" melos publish --scope"*package*"
``` ```
#### Badging ### Badging
In the package `readme.md` file, please specify the supported SDK: 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 & Flutter](https://img.shields.io/badge/SDK-Dart%20%7C%20Flutter-blue?style=flat-square)
```markdown ```markdown
![SDK: Dart & Flutter](https://img.shields.io/badge/SDK-Dart%20%7C%20Flutter-blue?style=flat-square) ![SDK: Dart & Flutter](https://img.shields.io/badge/SDK-Dart%20%7C%20Flutter-blue?style=flat-square)
``` ```
or or
@ -237,7 +256,9 @@ or
![SDK: Dart](https://img.shields.io/badge/SDK-Dart-blue?style=flat-square) ![SDK: Dart](https://img.shields.io/badge/SDK-Dart-blue?style=flat-square)
```markdown ```markdown
![SDK: Dart](https://img.shields.io/badge/SDK-Dart-blue?style=flat-square) ![SDK: Dart](https://img.shields.io/badge/SDK-Dart-blue?style=flat-square)
``` ```
--- ---
@ -251,10 +272,19 @@ dependencies:
wyatt_analysis: wyatt_analysis:
git: git:
url: https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages url: https://git.wyatt-studio.fr/Wyatt-FOSS/wyatt-packages
ref: wyatt_analysis-v2.0.0 ref: wyatt_analysis-v2.4.1
path: packages/wyatt_analysis path: packages/wyatt_analysis
``` ```
or the hosted version :
```yaml
dependencies:
wyatt_analysis:
hosted: https://git.wyatt-studio.fr/api/packages/Wyatt-FOSS/pub/
version: 2.4.1
```
Here you can change `package name` and `package version` . Here you can change `package name` and `package version` .
--- ---
@ -263,10 +293,32 @@ Here you can change `package name` and `package version`.
To sum up, here a simple work flow diagramm. To sum up, here a simple work flow diagramm.
![Dev Wokflow](doc/workflow.svg) ```plantuml
@startuml Simple Developpment Workflow
start
:Create an issue;
:Create branch related to the issue;
repeat :Commit related to the issue;
repeat while (feature is done)
:Update coverage;
:Close issue via last commit;
:Rebase from `master`;
:Create pull request;
:Merge branches;
:Update version;
:Publish package;
stop
@enduml
```
## Status ## Status
![Status: Experimental](https://img.shields.io/badge/Status-WIP-red?style=flat-square) ![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. This repository is maintained by Wyatt Studio but work is in progress.
## License
[![License: GPL v3](https://img.shields.io/badge/License-GPL%20v3-blue.svg)](http://www.gnu.org/licenses/gpl-3.0)
Thoses packages are licensed under the GNU General Public License v3.0. See the [LICENSE](LICENSE) file for details.

15
doc/work_flow.puml
View File

@ -1,15 +0,0 @@
@startuml Simple Developpment Workflow
start
:Create an issue;
:Create branch related to the issue;
repeat :Commit related to the issue;
repeat while (feature is done)
:Update coverage;
:Close issue via last commit;
:Rebase from `master`;
:Create pull request;
:Merge branches;
:Update version;
:Publish package;
stop
@enduml

25
doc/workflow.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 7.5 KiB