Flutter 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 and are available exclusively on this repository.

Usage

You can add any package of the packages/ sub directory in your project.

dependencies:
  wyatt_analysis:
    hosted: https://git.wyatt-studio.fr/api/packages/Wyatt-FOSS/pub/
    version: ^2.4.1

You can also use the git protocol. But it's not recommended since it's not handle version constraints.

Contribution

Clone this repo.

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

Prerequisite

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.
Melos. Melos is a tool that helps in managing Dart projects that have multiple packages. It can be installed using the following command:

dart pub global activate melos

Mason. Mason is used for code generation purposes. It can be installed by running the following command:

dart pub global activate mason_cli

Lcov. Lcov is a tool used to generate coverage data. It can be installed on macOS by running the following command:

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

mason upgrade
mason make wyatt_package_template \
  --package_name <name> \
  --description A new Wyatt package \
  --flutter false
  -o packages/<name>

Browse our bricks for more information.

The <name> variable in the above command is important and must be clear and understandable. (see Naming)

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.

You must use underscores in the name.
You must use the wyatt prefix for the package name.

For example, if the name is CRUD BLOC the following naming conventions should be used:

package name: wyatt_crud_bloc
example name: wyatt_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 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.

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:

scope/type/short-name

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 .

Commits

See Conventional Commits for commit guidelines.

tldr : type(scope): description #issue .

Here allowed values:

build for updating build configuration, development tools or other changes irrelevant to the user.
ci for changes to our CI configuration files and scripts.
docs for changes to 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.
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.
refactor for refactoring production code, e.g. renaming a variable.
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 for more information about commit hooks.

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. (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 (closes #issue_number) . For example:

feat(auth): add AWS support. (closes #31)

You can use close , closes , closed , fix , fixes , fixed , resolve , resolves or resolved .

Before pushing

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:validate-local # same as above but without Drone env variables
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:

git pull --rebase

You are already working on a branch:

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:

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:

melos run test:all

Publish your package

If package is ready for production, publish it by running the following command :

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)


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

Warning

Some packages requires Flutter, so please specify it.

Simple work flow diagramm

To sum up, here a simple work flow diagramm.

@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

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

License

Thoses packages are licensed under the GNU General Public License v3.0. See the LICENSE file for details.

Languages

Dart 97.5%

Shell 1%

HTML 0.9%

Ruby 0.2%

Swift 0.2%