Development

Before you start you need to pay attention to the following.

BIT

The role of BIT

We are using Bit for packaging our components, and determining its dependencies.

BIT CLI

Install dependencies

bit install

This is the equivalent of yarn install, but you should only run bit install. This will handle all dependencies, building your components locally, in your node modules folder.

Compile your components, locally

bit compile

Compiling is a step that you will have to repeat often. I rarely start my local development server without first compiling. Additionally, at times you might notice changes that are not showing on Storybook. You may want to try compiling and restarting Storybook’s local env.

Run local development server

bit start

Run build process, locally

bit build

This is good practice as it will help you catch any build issues, before you tag and export your changes.

Clear cache

bit clear-cache

I use this some times when I am unable to see a change reflected on local environments, either Bit or Storybook.


 

Storybook

The role of Storybook

Storybook is the documentation framework we’re using. There is a lot of documentation for Storybook, starting with our own research on it. Additionally you can find plenty on their own documentation site.

 

How to run Storybook

yarn storybook

Keep in mind any changes to imported components, or any files outside of the components will not recompile all the necessary source files, and you may have to CTRL+C and restart the local development server — running yarn storybook again.

 

How to build Storybook’s static docs

yarn build-storybook

These files need to be committed to the repo, as we’re using GitHub Pages to publish them, and connect them to Zeroheight.

 


Testing

How to run tests

yarn test

A couple of interesting things you can do with this:

  • --watch flag will keep it running, and test on every file change
  • -u will update outdated snapshots

 


Git repo

The role of our Git repo

In the context of our current Bit workflow, Git is our file system, and an integral part of our approval process. Committing code to the repo pushes the code to Bit, through GH Actions, and makes them available in our @carlsberggroup private registry. It also triggers a build and deploy for the MTA (Malty Test App). Therefore, when committing new code, or changes to existing components, these need to be committed to a new feature branch (please always follow the feature/* branch naming convention), and approved, before changes can be merged into our main branch, and pushed to Bit and MTA.

 

Repo workflow

We are using a trunk based repo approach. Please read more about it here.