@trafilea/afrodita-components

Afrodita Components ·

Reusable ReactJS components for Afrodita Design System.

Installation

Afrodita Components is avaiable as an npm package:

  npm install @trafilea/afrodita-components

Usage/Examples

import { ButtonPrimary } from '@trafilea/afrodita-components';

function App() {
  return <ButtonPrimary text="Click me!" onClick={() => console.log('Button clicked')} />;
}

Run Locally

Clone the project

  git clone https://github.com/trafilea/afrodita-components.git

Go to the project directory

  cd afrodita-components

Install dependencies

  npm install

Start storybook

  npm run storybook

Demo

Visit our Storybook deployed in Chromatic.

Releases

Versioning policy

In this section we define what versioning policy we’re using for this project. We follow Semantic Versioning principles, a well known and simple way of software versioning.

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release are available as extensions to the MAJOR.MINOR.PATCH format.

Major releases can also contain new features, and any release can include bug fixes.

For more information, visit this confluence document.

Releasing process

Note: In this project we’re using the Gitflow workflow.

Beta versions

Beta versions target the develop branch and they are not required. We’ll release new beta versions on demand. The CI/CD pipelines will take care of the deployment to the NPM repository every time a new version increment is detected.

• When the feature or bugfix is finished in its corresponding branch, increment the version number following the versioning policy. You can do it manually by updating the ‘version’ key in package.json or using npm-version that will increment the version number in package.json (major, minor or patch depending on the parameters), commit the change and create a tag with the same version number. For example: starting with 6.1.2 and running ‘npm version minor’, will increment to 6.2.0
• Start a pull request to develop and once merged the CI/CD pipelines will build and deploy the new version to the NPM repository, with the ‘beta’ tag.

Production versions

Production versions target the main branch. Ideally, we want to release new prod versions between medium or small intervals of time to let our consumers adopt the latest versions frequently. The CI/CD pipelines will take care of the deployment to the NPM repository every time a new version increment is detected.

• When we have a considerable amount of features or bugfixes ready to ship with the new version, increment the version number following the versioning policy. We can achieve this by incrementing the version number previously in the develop branch, or by creating a release (release/x.y.z) branch from develop and updating the version number in it. If opting for the second option, remember the Gitflow workflow for release branches.
• Create a tag with the version number.
• Start a pull request to main and once merged the CI/CD pipelines will build and deploy the new version to the NPM repository.
• Create a new Release in the github repository. Create the title following: vx.y.z (example: v1.0.1), choose the right tag, select the target branch and write a description with all the changes shipped with this new version.