Skip to content
Webclient development

Development workflow

Git Workflow

Uniform Repository Approach

All associated repositories adhere to a unified workflow. This ensures consistency and predictability across different components of our system.

Feature Development and Bug Fixes

  1. Branch Creation: For any new feature or bug fix, create a dedicated branch from the main master or whatever branch is the default. Name the branch appropriately to reflect its purpose (e.g., feature/your-new-feature, bugfix/issue-description).

  2. Development: Implement your changes in the newly created branch. Ensure that your code adheres to our coding standards and passes all tests. Note that you shouldn’t bump any version in the package.json file, as this will be done automatically by the release process.

  3. Committing Changes: Use conventional commit messages to document your changes. This assists in automated versioning and release note generation. A cheat sheet for conventional commit syntax will be provided later in this document.

  4. Merge to develop: Once your changes are ready, merge the changes into develop branch for review. Continuous integration tools and semantic-release will handle versioning and package updates.

  5. Testing in Develop: Features and fixes should be thoroughly tested in the develop environment.

  6. Merging to Main: Once verified in develop, merge the same branch into the main branch. This merge triggers the release process.

  7. Release: The release process, powered by Semantic Release, automatically versions the changes and publishes the package.

  8. Sync Develop with Main: After a release, ensure to update the develop branch with the latest content from main. This step is crucial to keep both branches in sync.

  9. Automatic Dependency Updates: Pushing commits to alpha, develop - v2-develop, or main - v2 will trigger a GitHub action that builds and publishes the affected library. On successful publication, an auto-generated PR is created. You should approve and merge this PR to update the dependent project.

Semantic Release and Conventional Commits

Semantic Release

Semantic Release automates the versioning and package publishing process based on our commit messages. It analyzes the commit messages to determine the type of version change (major, minor, or patch).

Conventional Commits

Conventional Commits provide a set of guidelines for creating expressive commit messages. They make it easier to manage our versions and release notes. Here’s a quick cheat sheet: The table below shows which commit message gets you which release type when semantic-release runs (using the default configuration):

Commit messageRelease type
fix(pencil): stop graphite breaking when too much pressure appliedPatch - Fix Release
feat(pencil): add 'graphiteWidth' optionMinor - Feature Release
perf(pencil): remove graphiteWidth option

BREAKING CHANGE: The graphiteWidth option has been removed.
The default graphite width of 10mm is always used for performance reasons.		Major - Breaking Release
(Note that the BREAKING CHANGE: token must be in the footer of the commit)

By adhering to this workflow and commit guidelines, we maintain a robust, consistent, and efficient development process.

Local environment setup

You can leverage the npm run link command in the webclient project to avoid publishing the libraries. This way you will be able to test features and your local development without pushing changes in Git. You must select the different libraries that you want to link in your local setup.

Terminal window
npm run link

And select the projects that you need to modify.