Set up a release pipeline #3
Conversation
| @@ -30,5 +33,8 @@ | |||
| }, | |||
| "peerDependencies": { | |||
| "react-dom": "^18.2.0" | |||
| }, | |||
| "publishConfig": { | |||
| "provenance": true | |||
There was a problem hiding this comment.
This will force your npm package to publish using GitHub. This gives your users confidence that what is being published is the same as what is on GitHub.
| # - name: Send a Slack notification if a publish happens | ||
| # if: steps.changesets.outputs.published == 'true' | ||
| # # You can do something when a publish happens. | ||
| # run: my-slack-bot send-notification --message "A new version of ${GITHUB_REPOSITORY} was published!" |
There was a problem hiding this comment.
If you want to set up a slack bot to publish messages whenever new versions are published you can use this.
| publish: bun release | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| NPM_TOKEN: ${{ secrets.NPM_TOKEN }} |
There was a problem hiding this comment.
In order for the action to be able to publish you need to generate an npm access token and it to your repositories secrets as NPM_TOKEN.
package.json
Outdated
| @@ -5,7 +5,9 @@ | |||
| "types": "dist/index.d.ts", | |||
| "scripts": { | |||
| "build": "bunx tsc", | |||
| "prepublishOnly": "bun run build", | |||
| "changeset": "changeset", | |||
| "prerelease": "pnpm build", | |||
There was a problem hiding this comment.
Thank you so much for this! This is the type of stuff i am totally blank on.
If i understand it correctly + some questions:
- Make changes (and commit??)
- Create a changeset. What does this do? Updates the package.json with the correct version and add some metadata that's stored in
.changeset? - If i push this to main, it creates an additional PR to main? What does this PR do?
- Will changeset only publish when a release-PR is merged? Or every time i push to main?
Probably some dumb questions here😅
Is there a reason why we need pnpm for building, and not use bun?
There was a problem hiding this comment.
The changesets that area created are just markdown files with some frontmatter describing the changes. They will typically look something like this:
.changeset/real-paws-leave.md (file names are randomized)
---
fallback-email: minor
---
Add MailGrid adapter Creating a changeset does not bump the version in package.json. When you push a changeset to main the release.yml action will either update or create a release PR. This release PR simply:
- Bumps the version in the packages
package.jsonaccording to the changesets in the repository.- For instance, if there is a patch changeset and a minor changeset the PR will be bumped to the next minor.
- Creates/appends the packages
CHANGELOG.mdwith this versions release notes (the changesets content) - Deletes all changesets
So the PR doesn't really do a release, it just does the dirty work of creating release notes and bumping versions for you.
Whenever something is pushed to main, the release.yml action tries to publish the package to npm. If the version already exists on npm it will not be able to publish, so nothing happens. However, if the version does not exist, for instance after merging a release PR that has bumped your version, the GitHub action will publish the new version to npm.
So it doesn't really matter how you add the changesets. Whenever a changeset is pushed to main it will be picked up by the action. You could also omit adding changesets, and instead manually bump the package.json. This will also lead to a release being made, however using changesets will generate release notes for you, which is nice 😄 These release notes are also the same release notes dependabot will be displaying in its PRs.
Is there a reason why we need pnpm for building, and not use bun?
Woops! Good catch! Just me being stupid 😅 I copied the setup from another project I've been working on, domstolene/designsystem. I pushed a fix for this now, using bun instead 😄
Here's an example of how a release PR looks like: domstolene/designsystem#1155
I also recommend adding the changesets bot to the repository. It will remind you to make changesets, and show you how changesets will bump the version, in PRs.
And, finally... only changes that needs to be released needs changesets. Changes to CI or similar that don't affect the users are fine to not create changesets for 😊
Hope this clears things up! If you have any other questions I'm happy to answer them for you 😄
Using changesets for the release pipeline. Pretty commonly used for publishing npm packages.
Using changesets for the release pipeline. Pretty commonly used for publishing npm packages.
With this setup making a release consists of:
bun changesetrelease.ymlGitHub Actionrelease.ymlGitHub Action will publish the changes