Wyatt Packages

Style: Wyatt Analysis Maintained with Melos

--- [[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: ![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.