@bloomreach/broccoli
Advanced tools
This is the component library formerly known as `br-ui` which is used by several Bloomreach applications. It is in maintenance mode and no new components will be added here. If you need a new component, you should go to the `@bloombreach/react-banana-ui`
This is the component library formerly known as br-ui which is used by several Bloomreach applications. It is in maintenance mode and no new components will be added here. If you need a new component, you should go to the @bloombreach/react-banana-ui library and create a new component.
Visit the library storybook to view the latest available components.
The current library should not be used in its own, it should be used only together with @bloomreach/react-banana-ui in the transition time.
If you have already used the old library @bloomreach/broccoli version 3 or less in your project you should migrate to the new library @bloomreach/react-banana-ui as soon as possible. The old library is in maintenance mode and no new components will be added. The new library is the main library for all components and will be actively developed and supported.
Please, follow the migration guide here.
Install all dependencies
npm ci
Run the storybook
npm run start
After that, any changes in the source code will automatically be reflected in the storybook.
To manage and automate complex release workflow based on multiple Git branches and distribution channels used the semantic-release library. Check the documentation for more details. The current setup is reduced and simplified as much as possible, however, it is flexible and might be extended in the future if needed.
The current branch types are explained below.
broccoli 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;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:
semantic-release configuration in ./.releaserc, check the documentation for more details;release job to allow running it with the new branch, check ./.gitlab-ci.yml;protected in the repository settings.Find more examples of possible release workflows in the official semantic-release documentation.
To have an automated release process the git commit messages must follow the following format. This specification following Conventional Commits. It provides an easy set of rules for creating an explicit commit history. This convention dovetails with semantic version, by describing the features, fixes, and breaking changes made in commit messages.
Each commit message consists of a header, a body, and a footer.
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and must conform to the Commit Message Header format.
The body is optional. When the body is present it must be at least 20 characters long and must conform to the Commit Message Body format.
The footer is optional. The Commit Message Footer format describes what the footer is used for and the structure it must have.
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.fix: and feat: are allowed, see types.Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: Right now not used but will be expanded in the near future.
│
└─⫸ Commit Type: build|chore|ci|docs|feat|feature|fix|perf|refactor|style|test.
The <type> and <summary> fields are mandatory, the (<scope>) field is optional and not used now.
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;feature - the alias for the typefeat;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.
Other prefixes are up to your discretion. Suggested prefixes are build, ci, docs ,style, refactor, style, test and chore for non-changelog related tasks.
Not used currently.
Use the summary field to provide a succinct description of the change:
Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".
Explain the motivation for the change in the commit message body. This commit message should explain why you are making the change. You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
The footer can contain information about breaking changes and is also the place to reference Jira tickets, and other MRs that this commit closes or is related to.
For example:
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
<Closes|Fixes> BR-<issue number>
Breaking Change section should start with the phrase BREAKING CHANGE: followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
Similarly, a Deprecation section should start with DEPRECATED: followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit.
The content of the commit message body should contain:
This reverts commit <SHA>,You should never create a new component here. This library is in maintain mode and no new components will be added here. If you need a new component, you should go to the @bloombreach/react-banana-ui library and create a new component.
The Storybook is used to view components in isolation.
The components stories are located in the ./stories folder.
When adding changes for any component part of the library it is mandatory to have them covered by tests. The tests should be added to the same folder where the component is located and should have the same name as the component with the .spec.ts(x) extension.
The Vitest unit test framework is used for the unit testing. The unit test files should end with *.spec.ts(x) and place close to the component or module which is going to be tested.
The release of the new version is going to be done automatically when the changes reach one of the release branches and commit messages contain one of the structural elements.
To preview the possible release version and release notes based on already existing commits run the following command
npm run release:dry-run
The Gitlab pipeline runs all the checks and if the library is in good order:
Only a few manual steps should be done after all:
released in the releases section in Jira once the ticket is merged and closed;FAQs
This is the component library formerly known as `br-ui` which is used by several Bloomreach applications. It is in maintenance mode and no new components will be added here. If you need a new component, you should go to the `@bloombreach/react-banana-ui`
We found that @bloomreach/broccoli demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 36 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
RubyGems.org has added a new "maintainer" role that allows for publishing new versions of gems. This new permission type is aimed at improving security for gem owners and the service overall.
Security News
Node.js will be enforcing stricter semver-major PR policies a month before major releases to enhance stability and ensure reliable release candidates.
Security News
Research
Socket's threat research team has detected five malicious npm packages targeting Roblox developers, deploying malware to steal credentials and personal data.