We use a feature-branching strategy. When making a pull request, make it to the develop branch.
These commit messages look like:
For example, adding a new component to the design system might have a commit message like:
feat indicates that this commit includes a new feature, and will trigger a minor version increase when merged into the main branch.
If you're just fixing a bug, you could use
fix instead, which will trigger a patch release.
The text inside the brackets indicates the scope of your changes. Normally this is the name of the component you're adding or changing. You could also use
core for changes to tooling, or
docs for pure documentation changes.
After the colon, you can write your commit message as normal.
You can read more about this format in the semantic-release docs.
We use Jest to run our tests.
Because many of our components are purely presentational and consist only of HTML and SCSS, we don't unit test them in the usual way. Instead, we use:
- axe to warn us about any accessibility issues in our markup
- jest-image-snapshot to warn us about unexpected visual regressions in our components, so we don't accidentally change the way components look
We use the documentation file for a component (in
docs/components) as the source material for these tests. This way you don't have to write seperate test cases.