If you find a bug or have a feature request, please create an issue and follow the issue template.
-
This project uses node.js and npm. npm comes preinstalled with node. You can install nodejs following the steps here: https://nodejs.org/en/
-
We keep the development experience consistent by making sure everyone is using the same (or compatible) nodejs/npm version with nvm run
nvm use
in the project root and this would automatically switch you to the correct version specified in .nvmrc -
The project is structured as a monorepo, run
npm run bootstrap
to install all necessary dependencies
- Check for open issues. Before you embark on a large pull request, it's usually a good idea to first check to see if an issue exists for the problem you're trying to solve. If one does, please add a comment to the existing issue instead of creating a new one.
- Create a branch. Create a branch for your work. The branch name should be
descriptive and can include the issue number. For example,
feature/1234-add-foo
. - Make changes. Make your changes. See the README in each package for more information about that package.
- Storybook. Use Storybook to test and document the components. For more information on how to use storybook, see the Storybook section below.
- Package specifics. Checkout individual package READMEs for more information about that package.
- Commit. Commit your changes. Follow the Conventional Commits specification. Checkout the Commit Messages & Versioning section below.
- Push. Push your changes to your branch.
- Create a pull request. Create a pull request from your branch to the
development
branch. - Review. Review your pull request. Make sure the CI checks pass and that someone else has reviewed your changes.
- Merge. Merge your pull request. If you don't have permission to merge, ask someone else to merge it for you.
- Delete your branch. You can delete your branch after the PR is merged.
- Publish. If you're a maintainer, publish the package to npm. See the Publishing section below.
Every package in the compassion-gds monorepo adheres to semantic versioning. In order to simplify the versioning and release process, please be sure your commit messages adhere to the “Conventional Commits” pattern. You may wish to install the commitizen/cz-cli to make this near-bulletproof.
We use Storybook to document and test our components.
Storybook renders components in their various states, and serves as
documentation of those components by surfacing code comments, Typescript prop typings and defaultProps
values.
To launch Storybook, make sure you’re in the package directory and run the command npm run storybook
.
After the project is built, Storybook will launch in your default browser. New components or modifications
will be displayed in real time! 🎉
We don't have a strict Publishing schedule.
The typical workflow is to publish a new version after a certain set of features are added or bugs are fixed.
If you are a maintainer you can publish the package to npm. To do this, run the following command:
npm run publish
This will run the following steps:
- Build. Build the package.
- Test. Run the tests.
- Lint. Run the linter.
- Version. Bump the version.
- Tag. Tag the release in git.
- Update the changelog. Update the changelog. (See the Changelog here).
- Publish. Publish the package to npm. section below.
- Update the documentation. Update the documentation.
- Update the website. Update designwithcompassion.com with relevant information.
- Update the examples. Update the examples
- Update the release notes. If you're a maintainer, update the release notes.
- Update the roadmap. If you're a maintainer, update the roadmap.