Commits

Commit convention

You'll need to follow the next Set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.

Every commit should follow the following structure: type(none or package_name | * when there are multiple packages, max three contexts or *): explaination_in_present_tense or type(*): explaination_in_present_tense (the last structure is when there's a cross change of none/multiple packages and multiple contexts)

There are a small list of types (below there's the list) and packages (their names are in the code folder packages).

---

List of types with examples

• fix: patches a bug in the codebase.

fix(entities, account, wallet): add the validation for privateKey when creating a new account

• feat: introduce a new feature to the codebase.

feat(nx): change default branch (it excludes the package name because it changes a file on the project general configuration)

feat(ui-components, progress button): add a progress button

• refactor: restructure the code, change the internal behavior of method.

refactor(ui-repositories, swap): split the code on multiple methods refactor(*, api): delete the creation of an instance (asterisk * means multiple packages have been touched)

refactor(entities, *): change name of a method (asterisk * means many contexts have been refactored)

• improv: an improvement of the code without fixing the code and doing a refactor
• docs: documentation like comments, explanation for classes, methods, etc.

docs(ui-common, error): add explanation for class Error docs(readme): add the section Contribute

• chore: periodic management task, like upgrading the dependencies, uploading documentation, etc.
• build: debugging (like edit VSCode configuration), modify git configuration like the file .gitignore, modify the build process, add new NPM commands, etc.