Versioning Process for Deployed npm Packages - HausDAO/daohaus-monorepo-deprecated GitHub Wiki
Overview
Now that several of our npm packages are deployed we have to bump the versions in the package.json for each impacted package. Each time we make a change that adds or removes anything from the package we have to adjust this before merging into master or the publication process will throw an error.
We have a basic process in place that we began using when initially deploying our packages for the 7/1/22 Alpha release. We have plans in place to iterate and improve this process, but we also wanted to document the current approach so that folks know the steps involved and what to be mindful of when making package changes.
Impacted Packages
This only applies to packages in our libs folder that are published to npm and not to any of our apps. As of now, these are the affected packages:
- SDK
- Component Library
- Commons
- DAOhaus Connect
- TxBuilder
Each of these is currently published on npm (mostly as alpha releases). The current version is contained in each package's package.json file.
When to Update
- When we merge a feature or fix branch into our
developbranch (or even directly intomasterin the case of a critical fix) the version needs to be bumped in the affected package'spackage.json. - Once the version has been updated the package will publish to
npmwhen merged intomaster - Version bumps can be done on a separate PR indicating this
Example Process
-
- Feature branch such as
feature/my-new-featureadding a feature to the SDK is approved and merged intodevelop
- As this is a change to a published package we need to bump the version in the
package.json
- Feature branch such as
-
- New PR is made on
developindicating a version increase
- New PR is made on
-
- The
developbranch is merged intomasterwhich kicks off thenpmpublish script
- The
If the version hasn't been bumped before step #3 the publish will fail, and the build will fail
Release CI Workflow
We now have a release workflow that can be run before develop is merged into master. this release is based on @jscutlery/semver and adds semantic versioning to our commit message flow through commitlintrc.json. The current commit lint settings turn off the semantic versioning message restrictions currently until we are ready to turn them on. This workflow will do the following:
- calculates new version of each lib (based on tagging)
- creates/updates a changelog.md file
- update package.json
- adds the tag to the current version (will consist of changes from the latest commit on develop vs the latest commit on master)
- creates a release
shot from Release task Version Bump event:
Once this workflow completes, we must open the pr the moloch bot created against develop:
This workflow currently runs on workflow_dispatch, meaning it is triggered manually from the cli or actions interface:
from the UI:
from the CI, run CI task
> gh workflow list
Ci branch active 24259143
Ci branch active 24259950
CI Release active 32026227
CI Test active 31780132
Nx migrate active 31137376
> gh workflow run 'CI Release' --ref develop
✓ Created workflow_dispatch event for develop at develop
To see runs for this workflow, try: gh run list --workflow=ci_release.yml
from the CI, view ci tasks
gh workflow view
? Select a workflow [Use arrows to move, type to filter]
Ci branch (ci_develop.yaml)
Ci branch (ci_master.yaml)
> CI Release (ci_release.yml)
CI Test (ci_test.yml)
Nx migrate (nx-migrate.yml)
# hit enter
CI Release - ci_release.yml
ID: 32026227
Total runs 12
Recent runs
✓ removing pr open command, add commitlint CI Release ci-add-nrwl-upgrade workflow_dispatch 2834400559
X chore: login CI Release ci-add-nrwl-upgrade workflow_dispatch 2828945616
X chore: i hate ci CI Release ci-add-nrwl-upgrade workflow_dispatch 2828693850
X chore: gdi CI Release ci-add-nrwl-upgrade workflow_dispatch 2828688499
X chore: freaking permissions?!@? CI Release ci-add-nrwl-upgrade workflow_dispatch 2828677978
To see more runs for this workflow, try: gh run list --workflow ci_release.yml
To see the YAML for this workflow, try: gh workflow view ci_release.yml --yaml