PR and changeset process

Create a .stories.tsx file and add a couple of examples of your component and its different variants. This is not published anywhere, but Storybook is great for demonstrating the props and accessibility best practices of your component, and can often times expose layout or functionality bugs you didn't think of. Make sure you have at least a Default example.

Tip: Copy the structure from another component's .stories.tsx file to quickly get started.

If applicable, make sure you've written documentation in a README.md in your component folder that describes the props and significant features of your code. Get inspired by other package README's for what kind of content and language to include.

Tip: When creating a new package the scaffolded README.md file contains some useful guidelines on how to write your documentation.

Always include a .test.tsx file in your component that tests your functionality from an accessible point of view, using React Testing Library and the Given-when-then approach. Read more about how to write these tests on Automated testing.

Tip: Run npm run test on your local branch so you don't have to wait for the pipeline to see if your branch passes.

Always test your code from an end-user point of view, with accessibility and inclusivity in mind;

• Mouse-pointer user
• Keyboard-only user
• Touch screen user
• Screen reader user

In addition to the above, we recommend that you manually test your component in our example-site environment in the same repo, putting on the hat of a developer using your new component and see how it feels and making sure everything works. This is something we like to do when reviewing other's PRs as well – try it like the consumer would.

We also recommend testing your code in different browsers, especially if using newer CSS techniques that have limited support.

Packages are versioned and published with changesets.

Changesets helps us specify if a change we are making to a package should be a patch, minor or major version change, keeps a change log and helps with publishing and final versioning.

The last step before your code is ready to be reviewed is to add a changeset; simply run npm run changeset and follow the prompts.

We strictly follow SEMVER (semantic versioning) for our changesets:

• major – when you make incompatible API changes.
• minor – when you add functionality in a backwards compatible manner.
• patch – when you make backwards compatible bug fixes.

We prefix the changeset summary with one of the following to help clarify the release summary when the time comes to publish the new component:

• Feature: – when new functionality is introduced.
• Improvement: – when existing functionality is improved.
• Fix: – when fixing a bug.

It's OK to create a pull request before it's ready for review, just add a [WIP] prefix to the PR name so that your co-workers know it's a work in progress.

When all of the above is pushed, it's time to add a PR description and any instructions/attachments that might be useful for your co-workers reviewing the code. It's always a good idea to read through your code diff to make sure you didn't miss anything or accidentally committed something.

Always include the JIRA ticket number in the PR name, e.g. FEG-100: A new component, that reviewers can reference.

Aim to get at least two reviewers and approvals from the team looking over your code. In addition to adding them as reviewers in Bitbucket, feel free to also message them that the PR is ready for review 🕵️‍♀️

We tend to be very thorough in our code reviews since we build things that a lot of people will use, and often there will be many suggestions or requests for change to your PR.

We use Bitbucket's Tasks to track these requested changes. When you get a comment requesting a change, simply Create a task from that comment so you don't forget. When the task is actioned and you have committed the change, check that task off and let your colleagues know it's ready for re-review.

When you have at least one approval you are good to merge your PR into the master branch and will be included in the next publish 🎉