Skip to main content

Contributing

It takes a village. This whole "design system" thing only works if engineers across Curology are empowered to help maintain and grow the system.

When it comes to making changes in Squeeze, we must be mindful of breaking existing features or bloating the codebase. Before you start writing code for Squeeze, ask yourself a few questions:

Any component changes or additions should be discussed with the UX team and Architecture teams.

As a first step, create a Linear ticket that outlines the problem you are facing and thoughts you have on solving it (including proposed component API changes). There are two issue types: Bug and Update. Creating either will automatically start a thread in #design-system, where you should engage both @uxteam and @team-architecture in discussion. Decisions should be recorded in the Linear ticket.

If you have questions before creating a Linear ticket, start a conversation in #design-system !

Once you've written your code, added the appropriate tests, and created a changeset, create a new pull request and assign it to the Arch team.

A merged pull request will automatically build a new version of @curology/ui-components-web, create a release, and deploy the updated docs site.

For a guides on developing for Squeeze, see Running Locally and Component Anatomy.

Versioning​

This project and its packages use Semantic Versioning, with changes to package versions managed via Changesets.

Every time a package is altered, a changeset must be created to describe what is new and to define which kind of version bump should be applied. This is done by calling pnpm changeset from the project root.

Examples of version bumps:

  • Patch: a bugfix that doesn't change a component's application
  • Minor: adding a new prop to a component
  • Major: removing a component prop or changing a component's API in a breaking way

The exception to this versioning is the documentation site located inside of apps/docs. There is no versioning of this application, and whatever is merged to main will be automatically deployed.

Releasing​

Builds of each package are triggered by either a merge to main or the creation of a new pull request. A new tag/release is created with each build, with builds associated with a pull request being marked "Pre-Release". Each pre-release build is suffixed with the latest commit SHA from the branch in question. This ensures unique artifacts, and makes it possible for consumers of the design system to try pre-release packages.

View Releases