This monorepo is managed using yarn and nx. Each package is independently versioned and published to the npm registry
.
Ensure you are running version 14 or 16 of node
and yarn is installed. We recommend using nvm or fnm to manage your installation of node
.
node --version
npm install -g yarn
Install the dependencies with yarn
. The first install might take a while. All subsequent installs should proceed more quickly.
yarn install
Now we run the build
command to compile our code to be ready for local development.
yarn build:components
You are now ready to begin development in the repo!
The recommended way to work in the repo is running Storybook
while you write your code. This will give you an environment to view your changes, and also serves as documentation once deployed.
yarn start
All new features should have a unit test added. The unit tests will run when you push your code. If you run the tests on your own the results will be cached. This means subsequent executions of yarn test
will only run tests against code that has changed.
Currently you cannot run all of the tests in watchmode. You can run watchmode for one package at a time. Here is an example for the app-icon
packge
yarn nx test app-icon --watch
This repo uses eslint-config-availity for linting. Make sure to have linting support in your IDE or run the linting script to make sure your code does not have any errors. You will not be able to commit your code if there are linting errors.
yarn lint
Managing dependencies in a monorepo is similar to a single package repo. The main difference is the command is longer. We are going to use the workspace
command from yarn
to tell yarn
which package we want updated.
Here is an exmaple of adding react-query
to the avatar
package
yarn workspace @availity/avatar add react-query
yarn new
The commit messages in this repository are important for two main reasons:
-
The
type
(feat, fix, build, etc) is used to determine how to bump the version when publishing. -
The commits with types
feat
andfix
will show up in theCHANGELOG.md
for the given package.
Commits should use the Angular Commit Format. Scope should be one of the un-prefixed names of the packages under ./packages/
or docusaurus
for the docs. If a commit applies to multiple packages, leave out the scope.
For example, here is what the commit message would like when fixing a null-checking error in the icon package:
git commit -m "fix(icon): check for null before doing the action"
In order to bump a package by a major version you must indicate a BREAKING CHANGE
in the commit message. Read through the conventional commits for more information
git commit -m "feat(table)!: add new features
BREAKING CHANGE: names of props changed"
Canary Releases can be used to test changes without impacting the latest
tag.
The first thing we need to do is create a new version to be tagged. Version bumps are generated off the latest commits to the package. You should commit any changes before running the version and publish commands.
Bump the version using a preid
. The preid
is the tag you want to use in order to identify the release. If you want to see what version will be created without actually making the changes, then add the --dry-run
flag to the end.
# This will make changes to the package.json, changelog.md, and make a commit
yarn nx version app-icon --releaseAs=prerelease --preid=alpha
# Dry run to make sure changes are correct
yarn nx version app-icon --releaseAs=prerelease --preid=alpha --dry-run
Once you have a newly created version it will need to be published to the registry so you or others can use it. First login, and then run the publish command
# login
yarn npm login --publish
# publish
yarn nx publish:canary app-icon