@bloomreach/react-banana-ui 1.26.0 → 1.27.1

package/README.md

@@ -4,17 +4,14 @@ This is a component library of all basic and common components across all
 bloomreach project apps. This will be primarily primitive components and
 possibly some specialized items as well.
 
-
 ## Viewing Available Components
 
 Visit the library [storybook](https://design.corp.bloomreach.com/storybooks/react-banana-ui/master/) to view the latest available components.
 
-
 ## Guide from Figma Design to the React Banana UI Components
 
 Use the following [guide](./docs/guide-from-figma-to-rbui.md) to translate a Figma design into a functional page using RBUI components.
 
-
 ## Using library in a project
 
 Install the library as a dependency in the project
@@ -35,7 +32,7 @@ import { <ComponentName> } from "@bloomreach/react-banana-ui";
 
 Do the following steps to make styles and fonts available
 
-* Import the library styles in the main application style file as the following line
+- Import the library styles in the main application style file as the following line
 
   ```css
   // main.scss
@@ -44,7 +41,8 @@ Do the following steps to make styles and fonts available
 
   ...
   ```
-* The font family for your `html` and `body` tags are already specified in the library styles
+
+- The font family for your `html` and `body` tags are already specified in the library styles
 
 ### IMPORTANT
 
@@ -52,14 +50,15 @@ Please, avoid using `--rbui-...` and/or `--banana-...` CSS custom properties dir
 as they are intended to be used inside the library only.
 Stick to use library components to bring the styles into the application.
 
-
 ## Development
 
 ### Prerequisites
+
 - Node.js (latest LTS)
 - NPM (latest, compatible with Node.js)
 
 Install all dependencies
+
 ```sh
 npm ci
 ```
@@ -78,17 +77,16 @@ To manage and automate complex release workflow based on multiple Git branches a
 
 The current branch types are explained below.
 
-* The `master` branch - is a permanent branch, where releases happen for the latest versions. All versions from that branch will be published to the npm registry with a `latest` dist-tag;
-* The `next` branch should be used when we want to develop an important feature, which is a breaking change. Considering the scope of this feature we want to make it available, at first, only to a limited amount of users in order to get feedback or run tests. Once we get that feedback we can make improvements and ultimately make the new feature available to all users by merging changes into the `master` branch; Releases from the `next` branch will be published to the npm registry with a `next` dist-tag;
-* The maintenance branches (i.e. `2.x` to maintain release `v2`). The maintenance branch is a type of branch that allows publishing releases with a [semantic version](https://semver.org/) on top of the codebase of an old release. This is useful when you need to provide fixes or features to users who cannot upgrade to the last version of the package;
-* Feature branches (like `feature/BR-XX-my-awesome-feature`, `fix/BR-XX-that-is-life`) or any other kind of branch to commit small units of work that do not produce releases (until merged into one of the branches above). These branches are ignored from now on as they don’t have to trigger releases;
-
+- The `master` branch - is a permanent branch, where releases happen for the latest versions. All versions from that branch will be published to the npm registry with a `latest` dist-tag;
+- The `next` branch should be used when we want to develop an important feature, which is a breaking change. Considering the scope of this feature we want to make it available, at first, only to a limited amount of users in order to get feedback or run tests. Once we get that feedback we can make improvements and ultimately make the new feature available to all users by merging changes into the `master` branch; Releases from the `next` branch will be published to the npm registry with a `next` dist-tag;
+- The maintenance branches (i.e. `2.x` to maintain release `v2`). The maintenance branch is a type of branch that allows publishing releases with a [semantic version](https://semver.org/) on top of the codebase of an old release. This is useful when you need to provide fixes or features to users who cannot upgrade to the last version of the package;
+- Feature branches (like `feature/BR-XX-my-awesome-feature`, `fix/BR-XX-that-is-life`) or any other kind of branch to commit small units of work that do not produce releases (until merged into one of the branches above). These branches are ignored from now on as they don’t have to trigger releases;
 
 The following changes should be done to change or extend the current setup:
 
-* Add a new release/maintenance/pre-release branch to the `semantic-release` configuration in `./.releaserc`, check the [documentation](https://semantic-release.gitbook.io/semantic-release/usage/configuration#branches) for more details;
-* Update the Gitlab pipeline `release` job to allow running it with the new branch, check `./.gitlab-ci.yml`;
-* Verify that the new branch is marked as `protected` in the repository settings.
+- Add a new release/maintenance/pre-release branch to the `semantic-release` configuration in `./.releaserc`, check the [documentation](https://semantic-release.gitbook.io/semantic-release/usage/configuration#branches) for more details;
+- Update the Gitlab pipeline `release` job to allow running it with the new branch, check `./.gitlab-ci.yml`;
+- Verify that the new branch is marked as `protected` in the repository settings.
 
 Find more examples of possible release workflows in the official `semantic-release` [documentation](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow).
 
@@ -115,11 +113,11 @@ The `footer` is optional. The [Commit Message Footer](#commit-message-footer) fo
 
 ### The commit contains the following structural elements:
 
-* `fix`: a commit of the type fix patches a bug in your codebase (this correlates with `PATCH` in Semantic Versioning).
-* `feat`: a commit of the type feat introduces a new feature to the codebase (this correlates with `MINOR` in Semantic Versioning).
-* `BREAKING CHANGE`: a commit that has a footer BREAKING CHANGE:, or appends a `!` after the `type/scope`, introduces a breaking API change (correlating with `MAJOR` in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
-* types other than `fix`: and `feat`: are allowed, see [types](#type).
-* footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
+- `fix`: a commit of the type fix patches a bug in your codebase (this correlates with `PATCH` in Semantic Versioning).
+- `feat`: a commit of the type feat introduces a new feature to the codebase (this correlates with `MINOR` in Semantic Versioning).
+- `BREAKING CHANGE`: a commit that has a footer BREAKING CHANGE:, or appends a `!` after the `type/scope`, introduces a breaking API change (correlating with `MAJOR` in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
+- types other than `fix`: and `feat`: are allowed, see [types](#type).
+- footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
 
 Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a **BREAKING CHANGE**).
 
@@ -141,17 +139,17 @@ The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is opti
 
 Must be one of the following:
 
-* `build` - changes that affect the build system or external dependencies; Hidden from the release notes;
-* `chore` - changes which are not fit to the rest of the types. Hidden from the release notes;
-* `ci` - changes to our CI configuration files and scripts. Hidden from the release notes;
-* `docs` - documentation only changes. Hidden from the release notes;
-* `feat` - a new feature. Appeared in the release notes under section `Features`;
-* `fix` - a bug fix. Appeared in the release notes under section `Bug Fixes`;
-* `perf` - a code change that improves performance. Appeared in the release notes under section `Performance Improvements`;
-* `refactor` - a code change that neither fixes a bug nor adds a feature. Hidden from the release notes;
-* `revert` - revert of the previous changes. Appeared in the release notes under section `Reverts`;
-* `style` - changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc). Hidden from the release notes;
-* `test` - adding missing tests or correcting existing tests. Hidden from the release notes.
+- `build` - changes that affect the build system or external dependencies; Hidden from the release notes;
+- `chore` - changes which are not fit to the rest of the types. Hidden from the release notes;
+- `ci` - changes to our CI configuration files and scripts. Hidden from the release notes;
+- `docs` - documentation only changes. Hidden from the release notes;
+- `feat` - a new feature. Appeared in the release notes under section `Features`;
+- `fix` - a bug fix. Appeared in the release notes under section `Bug Fixes`;
+- `perf` - a code change that improves performance. Appeared in the release notes under section `Performance Improvements`;
+- `refactor` - a code change that neither fixes a bug nor adds a feature. Hidden from the release notes;
+- `revert` - revert of the previous changes. Appeared in the release notes under section `Reverts`;
+- `style` - changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc). Hidden from the release notes;
+- `test` - adding missing tests or correcting existing tests. Hidden from the release notes.
 
 If the prefix is `feat`, `fix`, `perf` or `revert`, it will appear in the release notes. However if there is any **BREAKING CHANGE**, the commit will always appear in the changelog.
 
@@ -162,11 +160,12 @@ Other prefixes are up to your discretion. Suggested prefixes are `build`, `ci`,
 Not used currently.
 
 #### Summary
+
 Use the summary field to provide a succinct description of the change:
 
-* use the imperative, present tense: "change" not "changed" nor "changes"
-* don't capitalize the first letter
-* no dot (.) at the end
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize the first letter
+- no dot (.) at the end
 
 ### Commit Message Body
 
@@ -199,9 +198,8 @@ If the commit reverts a previous commit, it should begin with `revert: `, follow
 
 The content of the commit message body should contain:
 
-* information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
-* a clear description of the reason for reverting the commit message.
-
+- information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
+- a clear description of the reason for reverting the commit message.
 
 ## Creating a new component
 
@@ -224,7 +222,6 @@ component-name.test.tsx // E2E tests
 
 **Note**: The script doesn't create the `index.ts` file inside `./src/components/<group>` folder. It should be created manually or updated already existing `index.ts` file.
 
-
 ## Storybook
 
 The [Storybook](https://design.corp.bloomreach.com/storybooks/react-banana-ui/master/) is used to develop and view components in isolation. The storybook files should end with `*.stories.tsx` and be placed close to the component or module which is going to be documented for all new or rewritten components. The `./stories` folder should locate only generic information about the library itself and additionally, complex stories involving multiple components.
@@ -283,14 +280,14 @@ npm run release:dry-run
 
 The Gitlab pipeline runs all the checks and if the library is in good order:
 
-* The [release notes](./RELEASE_NOTES.md) will be updated according commit messages history;
-* The library version will be bumped;
-* The new commit will be created with a version and changed release notes;
-* The new git tag will be created in the repository;
-* The new version of the library will be published to npm;
+- The [release notes](./RELEASE_NOTES.md) will be updated according commit messages history;
+- The library version will be bumped;
+- The new commit will be created with a version and changed release notes;
+- The new git tag will be created in the repository;
+- The new version of the library will be published to npm;
 
 Only a few manual steps should be done after all:
 
-* Announce in the slack channel [#react-banana-ui-component-library](https://bloomreach.slack.com/archives/C05E4672ZLZ) about new release :tada:;
-* Mark the new version as `released` in the [releases section in Jira](https://bloomreach.atlassian.net/projects/BU?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page) once the ticket is merged and closed;
-* Take a break and then pick up the next challenge :muscle:!
+- Announce in the slack channel [#react-banana-ui-component-library](https://bloomreach.slack.com/archives/C05E4672ZLZ) about new release :tada:;
+- Mark the new version as `released` in the [releases section in Jira](https://bloomreach.atlassian.net/projects/BU?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page) once the ticket is merged and closed;
+- Take a break and then pick up the next challenge :muscle:!