Design tokens are platform-agnostic design decisions that encapsulate our brand. They are the foundation to building user interfaces and new experiences. We write tokens in the DTCG format.
We use Style Dictionary to transform tokens into CSS custom properties, ES modules, and CommonJS modules.
Our icons are delivered as a SVG sprite that is then referenced in a React wrapper component.
Our components are built using React. React is simple to use and has strong TypeScript support, making it easy to encapsulate state and expose functionality through properties for components. We use TypeScript to write cleaner code and provide strong editor integration for consumers of our components. Our styles are written in CSS and live alongside components. Plain CSS offers the best long-term caching and its latest features help address many of the issues CSS frameworks seek to solve, without a cost to performance.
We use pnpm as our package manager for its speed, space efficiency, and strong monorepo support.
We use Storybook to build and test our components in isolation. It also provides us a means to document and communicate component API to engineers through story examples and args tables.
Our packages are built using Vite for its speed, rich features, and ease to customize. Packages are built in ESM and CJS formats. Type declarations are emitted using the TypeScript compiler.
Nx is used to run lint, test, and build scripts on only the packages affected by code changes. Its speed, caching abilities, and project graph features make it ideal for our project.
We use Vitest to run our unit tests as it is Jest compatible, supports ESM and TypeScript by default, generates c8 code coverage, and provides an instant watch mode. React Testing Library is used to test our React components and write tests that closely resemble how a user would interact with our components.
To test for visual regressions and accessibility we use Chromatic to run checks on Storybook stories.
We use Biome to highlight problems in our code and Biome to format it to be consistent across the repo.
Commits, branch names, and pull request titles follow the Conventional Commits specification to create an explicit commit history and communicate intent/scope of changes to consumers.
We use Changesets for versioning and releasing our packages. It empowers contributors to declare how their changes should be released via a changeset, a markdown file containing semver bump types with a summary of the changes made. The tool is able to process these changesets to update package versions and changelogs.