Coding standards

We use a feature-branching strategy. When making a pull request, make it to the develop branch.

Commit messages#

We use Angular commit message conventions. This lets us automatically release new versions to NPM with accurate semver version numbers.

These commit messages look like:

<type>(<scope>): <short summary>

For example, adding a new component to the design system might have a commit message like:

feat(component-xyz): Added component xyz

The keyword 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.

Testing#

We use Jest to run our tests.

If you add a component that includes JavaScript, you must add jest unit tests for it.

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.