Thank you for your interest in contributing to the Coinbase Design System! While we are not actively soliciting contributions, we welcome issue reports and are open to reviewing pull requests from the community.
If you encounter a bug, have a feature request, or notice something that could be improved, please open an issue. Include a clear description, steps to reproduce (for bugs), and screenshots if applicable.
- Fork the repository
- Follow the contributor setup guide for Node, Gradle, or Xcode
- Setup a GPG key for signing commits
The contributor hub also covers validation commands and CI behavior.
CDS has separate implementations for web, React Native, native Android, and native iOS. When fixing bugs or adding features, check whether the change applies to more than one platform. See all available packages.
When making changes:
- Update documentation if appropriate
- Update Storybook if there are visual changes
- Add or update tests
- Follow the testing and validation guide for every changed project
- Ensure your fork is up to date with the upstream
masterbranch - Create a new branch from
masterfor your changes - Push your branch to your fork
- Open a pull request from your fork's branch to
coinbase/cds:master - Fill out the PR template completely
For detailed instructions, see GitHub's guide on creating a pull request from a fork.
PR titles must follow Conventional Commits format:
<type>(<scope>): <description>
Examples:
feat: add new Button variantfix: resolve ListCell tap handler issue on mobilechore: update dependencies
Fill out the pull request template completely, including:
- What changed and why
- Before/after screenshots for UI changes
- How it was tested (unit tests, manual testing on web/iOS/Android)
Versioning and release procedures differ by package and toolchain. Follow the versioning and release guide; do not apply Node release commands to native Android or native iOS artifacts.
CDS versions packages with nx release version plans. Instead of editing package.json and CHANGELOG.md by hand, you commit a small markdown file describing your change, and nx release derives the version bump and changelog entry from it.
Use the Versioning section in README when choosing whether a change is major, minor, or patch.
# Write a version plan describing your change
yarn nx release planThe generator will prompt you for:
- Changed package(s) (web, mobile, common, etc.)
- Type of change (major, minor, or patch)
- Changelog message
Then apply the plan, which writes the new version and changelog entry:
yarn releaseCommit both the plan and the resulting package.json and CHANGELOG.md changes. CI fails if you changed a publishable package without either a version plan or a version bump.
See the release guide for the full workflow, including how to defer a release to a later batch.
Request a review from a maintainer, who will trigger CI and review your changes.
Thank you for contributing to CDS! If you have questions, feel free to open an issue for discussion.