sms-ui

UI library for SMS Platform project

Getting started

To install project:

yarn install

To run storybook:

storybook dev -p 6006

Git flow

1. Create new branch from the latest develop;
2. Apply changes that you need;
3. Fill up CHANGELOG.md file;
4. Commit changes and push;
5. Create Merge Request.

Release flow

1. Create new branch from the latest develop with prefix release, for example(release/1.0.1);
2. Define new version number in package.json;
3. In CHANGELOG.md file create new release note and move all changes from Waiting for release to the new release;
4. Commit changes;
5. Create new tag (git tag -a v1.0.1 -m 'version 1.0.1');
6. Push changes;
7. Create merge request from release/1.0.1 to master branch;
8. Merge to master branch;
9. Push tag (git push origin v1.0.1);
10. Create new branch from the latest master (sync-master-and-develop-release-1.0.1);
11. Create merge request from sync-master-and-develop-release-1.0.1 to develop branch;
12. Merge to develop branch.

Branch naming convention

Each branch must have one common structure (exceptions can be master, develop and so on).

<type>/[optional scope]-<description>

Type

There are 5 possible types:

• feat/: Feature branches for adding new functionality.
• fix/: Branches for fixing bugs.
• hotfix/: Urgent branches to address critical issues in production.
• release/: Branches for preparing a new release.
• refactor/: Branches for code refactoring.

Scope

As optional scope we must use ticket identifier (SPV0-404, PROJ-123) from issues tracking tool (Jira).

Description

Description can be any words which divided by dash symbol -.

Examples:

feat/SPV0-211-button-component

fix/SPV0-404-rename-error-text

hotfix/change-proxy-ip

release/1.22.2

refactor/SPV0-400-remove-unnecessary-button-props

Commits convention

For our project was chosen convention based on Conventional Commits. Current approach allows us to have particular structure, describing the features, fixes, and breaking changes made in commit messages.

All commits should have next structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Type

Must be one of the following:

• feat: A new feature;
• fix: A bug fix;
• docs: Documentation only changes;
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc);
• refactor: A code change that neither fixes a bug nor adds a feature;
• perf: A code change that improves performance;
• test: Adding missing tests;
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation.

Scope

The scope could be anything specifying place of the commit change.

Here are a few examples of commit messages using scopes:

feat(auth): Implement OAuth2 authentication strategy.

fix(database): Resolve connection timeout issue.

docs(readme): Update installation instructions.

refactor(utils): Extract common helper functions.

test(user): Add integration tests for user registration.

perf(database): Optimize database query for faster response times.

style(components): Format code according to component style guide.

Braking changes

Breaking changes are specifically identified and communicated in commit messages using the keyword "BREAKING CHANGE:". This allows developers to easily recognize and understand the impact of a commit on the codebase and its compatibility with existing functionality.

To indicate a breaking change in a commit message, the convention recommends adding the "BREAKING CHANGE:" keyword followed by a description of the breaking change. Here's an example:

feat: Add new authentication module

BREAKING CHANGE: The user schema has been updated to include a new 'role' field. Existing user records will need to be updated to include this field for proper functionality.

Also, you can define breaking changes using ! symbol.

Commit message with ! to draw attention to breaking change

feat!: send an email to the customer when a product is shipped

Commit message with scope and ! to draw attention to breaking change

feat(api)!: send an email to the customer when a product is shipped

Commit message with both ! and BREAKING CHANGE footer

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Body and footer

Optionally you can provide more details in the body or footer section.

Commit message with multi-paragraph body and multiple footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Changelog convention

Making new changes we need to fill up CHANGELOG.md file as well.

Changes must be added to the last release. Fixes to Bugs and features and new things to Features refactoring and improvements to Improvements.

Unreleased stuff must be placed to the Waiting for release section.

❗Attention:

Examples:

Waiting for release:

🐛 Bugs:

• [SearchSelect] Fix fetching data when select scrolled down.

@sms-platform/[email protected]

22-06-2023

🚀 Features:

• [UploadButton] Reexport UploadButton component from rmm.

• [Spin] Reexport Spin component from rmm.

🛠️ Improvements:

• [Spin] Create Spinner sub component.

🐛 Bugs:

• [Components] Export missing components from src folder.

Semantic versioning

The version number in package.json follows the semantic versioning format, which consists of three parts: MAJOR.MINOR.PATCH. Each part has a specific meaning:

• MAJOR version: When you make incompatible changes to the package, you increment the MAJOR version. These changes may include API changes that can potentially break existing functionality in dependent code.

• MINOR version: When you add new features or enhance existing functionality in a backward-compatible manner, you increment the MINOR version. These changes should not break existing code that depends on the package.

• PATCH version: When you make backward-compatible bug fixes or other patches, you increment the PATCH version. These changes address issues without introducing new features or breaking existing functionality.

More details you can read here.