ci: introduce changesets #9502
ci: introduce changesets #9502
Conversation
|
View your CI Pipeline Execution ↗ for commit 64146bf
☁️ Nx Cloud last updated this comment at |
|
Sizes for commit 64146bf:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9502 +/- ##
=======================================
Coverage 46.38% 46.38%
=======================================
Files 214 214
Lines 8488 8488
Branches 1919 1921 +2
=======================================
Hits 3937 3937
Misses 4108 4108
Partials 443 443 🚀 New features to boost your workflow:
|
| workflow_dispatch: | ||
| inputs: | ||
| tag: | ||
| description: override release tag | ||
| required: false |
There was a problem hiding this comment.
I think we need this to trigger manual releases from the github actions workflow
There was a problem hiding this comment.
or rather, we “needed” this. how can I force publish a release with changesets only?
There was a problem hiding this comment.
Yes you can do this with changesets alone!
| ## Releases | ||
|
|
||
| For each new commit added to `main` with `git push` or by merging a pull request or merging from another branch, a GitHub action is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities. | ||
| For each new commit added to `main`, a GitHub Workflow is triggered which runs the [Changesets Action](https://github.com/changesets/action). This generates a preview PR showing the impact of all changesets. When this PR is merged, the package will be published to NPM. |
There was a problem hiding this comment.
this sounds like more work for maintainers. Previously, I just merged a PR with fix: or feat: prefix in the commit message (which I could alter while squash merging if someone didn’t do that correctly) and it would auto-trigger a release. Now I have to:
- generate a changeset or remind people to do that
- wait for the preview PR to show up
- merge that, too
There was a problem hiding this comment.
Hey @TkDodo , yes it's definitely an extra step, maybe this wasn't explicitly addressed in that Discord thread. I'll still advocate for this change as I believe the downsides are outweighed by the benefits, but happy to discuss further on Discord!
| ## Commit message conventions | ||
| ## Changesets | ||
| `TanStack/query` is using [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). | ||
| We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**. | ||
| ### Commit Message Format | ||
| Each commit message consists of a **header**, a **body** and a **footer**. The header has a special | ||
| format that includes a **type**, a **scope** and a **subject**: | ||
| ```text | ||
| <type>(<scope>): <subject> | ||
| <BLANK LINE> | ||
| <body> | ||
| <BLANK LINE> | ||
| <footer> | ||
| ``` | ||
| The **header** is mandatory and the **scope** of the header is optional. | ||
| Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools. | ||
| ### Type | ||
| Must be one of the following: | ||
| - **feat**: A new feature | ||
| - **fix**: A bug fix | ||
| - **docs**: Documentation only changes | ||
| - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.) | ||
| - **refactor**: A code change that neither fixes a bug nor adds a feature | ||
| - **perf**: A code change that improves performance | ||
| - **test**: Adding missing or correcting existing tests | ||
| - **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation | ||
| ### Scope | ||
| The scope could be anything specifying place of the commit change. For example `query-core`, `react-query` etc... | ||
| You can use `*` when the change affects more than a single scope. | ||
| ### Subject | ||
| The subject contains succinct description of the change: | ||
| - use the imperative, present tense: "change" not "changed" nor "changes" | ||
| - don't capitalize first letter | ||
| - no dot (.) at the end | ||
|
|
||
| ### Body | ||
|
|
||
| Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. | ||
|
|
||
| ### Footer | ||
|
|
||
| The footer should contain any information about **Breaking Changes** and is also the place to [reference GitHub issues that this commit closes](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue). | ||
|
|
||
| **Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this. | ||
|
|
||
| ### Example | ||
|
|
||
| Here is an example of the release type that will be done based on a commit messages: | ||
|
|
||
| | Commit message | Release type | | ||
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | | ||
| | fix(pencil): stop graphite breaking when too much pressure applied | Patch Release | | ||
| | feat(pencil): add `graphiteWidth` option | ~~Minor~~ Feature Release | | ||
| | perf(pencil): remove `graphiteWidth` option<br/><br/>BREAKING CHANGE: The `graphiteWidth` option has been removed.<br/>The default graphite width of 10mm is always used for performance reasons. | ~~Major~~ Breaking Release | | ||
|
|
||
| ### Revert | ||
|
|
||
| If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
There was a problem hiding this comment.
Hello,
I noticed that the commit message conventions section in the CONTRIBUTING.md appears to be removed in this update, so I wanted to check.
Could you please share if there is any particular reason or background for removing this section?
Since it seems to be an important part of maintaining the team’s commit message conventions, I’d like to better understand.
Thank you!
There was a problem hiding this comment.
Hey @sukvvon , the commit messages are currently more important because they directly influence versioning logic. With changesets, the commit messages no longer affect versioning. I'm happy to keep in a section about writing good commit messages, but I don't think it needs to be as extensive!
There was a problem hiding this comment.
Hey @sukvvon , the commit messages are currently more important because they directly influence versioning logic. With changesets, the commit messages no longer affect versioning. I'm happy to keep in a section about writing good commit messages, but I don't think it needs to be as extensive!
https://github.com/pmndrs/zustand/blob/main/CONTRIBUTING.md#committing
How about referring to the link above? It’s a brief version I wrote before, and I think it can meet our needs!
WalkthroughAdds Changesets-based release tooling and config, replaces a custom publish script and CI publish step with Changesets steps, updates package scripts and devDependencies, introduces a PR template, updates CONTRIBUTING, and adjusts one integration package.json metadata. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as Developer
participant Repo as Repository
participant CI as GitHub Actions
participant CS as Changesets Action
participant Registry as Package Registry
Dev->>Repo: Push commits (may include a changeset)
activate CI
CI->>CI: Run tests & checks
CI->>CS: Run `changeset version`
CS-->>Repo: Create version & changelog updates
CI->>Repo: Commit & push version files (GITHUB_TOKEN)
deactivate CI
Dev->>Repo: Merge PR / push to main
activate CI
CI->>CS: Run `changeset publish`
CS->>Registry: Publish packages
CS-->>Repo: Update releases/changelogs
deactivate CI
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
Comment |
lachlancollins
force-pushed
the
changesets
branch
from
97cd385 to
fd8e6f0
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
package.json (2)
32-34: Add a status script for local DX.Consider adding a convenience script to preview pending releases locally.
Apply:
"prettier:write": "pnpm run prettier --write", "docs:generate": "node scripts/generateDocs.ts", "verify-links": "node scripts/verify-links.ts", "changeset": "changeset", "changeset:version": "changeset version && pnpm install --no-frozen-lockfile && pnpm prettier:write", "changeset:publish": "changeset publish" + ,"changeset:status": "changeset status --since=origin/main"
47-47: Changelog provider dependency: LGTM; document its output style.Looks good. Consider mentioning in CONTRIBUTING the “github‑compact” format so contributors know what to expect in PRs.
.github/pull_request_template.md (1)
7-9: Fix link to the correct Contributing guide in this repo.The template points to TanStack/config. Link should reference TanStack/query.
Apply:
- - [ ] I have followed the steps listed in the [Contributing guide](https://github.com/TanStack/config/blob/main/CONTRIBUTING.md). + - [ ] I have followed the steps listed in the [Contributing guide](https://github.com/TanStack/query/blob/main/CONTRIBUTING.md).CONTRIBUTING.md (2)
158-160: Typo: duplicate “run”.Small nit.
-This repo uses [Changesets](...) to automate releases. If your PR should release a new package version (patch, minor, or major), please run run `pnpm changeset` and commit the file. +This repo uses [Changesets](...) to automate releases. If your PR should release a new package version (patch, minor, or major), please run `pnpm changeset` and commit the file.
170-170: Clarify when the preview PR is created.Make it explicit that the preview PR appears only when changesets are present.
-For each new commit added to `main`, a GitHub Workflow is triggered which runs the Changesets Action. This generates a preview PR showing the impact of all changesets. When this PR is merged, the package will be published to NPM. +On pushes to `main`, a GitHub Workflow runs the Changesets Action. If there are pending changesets, it opens/updates a preview PR showing the release impact. When that PR is merged, packages are published to npm.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (7)
.changeset/config.json(1 hunks).github/pull_request_template.md(1 hunks).github/workflows/release.yml(3 hunks)CONTRIBUTING.md(2 hunks)integrations/angular-cli-20/package.json(1 hunks)package.json(2 hunks)scripts/publish.ts(0 hunks)
💤 Files with no reviewable changes (1)
- scripts/publish.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Preview
- GitHub Check: Test
🔇 Additional comments (6)
package.json (1)
44-44: Changesets CLI dependency: LGTM.Pinned to a recent version; aligns with the workflow step.
.changeset/config.json (1)
2-13: Config aligns with the Action usage.
- github‑compact changelog with repo set: OK
- commit: false pairs fine with the Action’s commit/title inputs
- baseBranch/main and public access: OK
No changes required.
.github/workflows/release.yml (2)
17-17: Permission update: LGTM.pull-requests: write is required for the Changesets Action to open/update the version PR.
38-47: Consider re‑adding a manual trigger for emergency/forced releases.You removed workflow_dispatch; maintainers asked about manual releases previously. Re‑introducing it keeps flexibility for hotfixes.
Apply:
on: - push: + push: branches: [main, alpha, beta, rc, v4] + workflow_dispatch: + inputs: + mode: + description: "Run version or publish" + required: false + default: "auto" + type: choice + options: + - auto + - version + - publishOptionally gate the step:
- - name: Run Changesets (version or publish) + - name: Run Changesets (version or publish) uses: changesets/action@v1.5.3 with: - version: pnpm run changeset:version - publish: pnpm run changeset:publish + version: ${{ inputs.mode == 'publish' && 'false' || 'pnpm run changeset:version' }} + publish: ${{ inputs.mode == 'version' && 'false' || 'pnpm run changeset:publish' }} commit: 'ci: Version Packages' title: 'ci: Version Packages'CONTRIBUTING.md (1)
164-167: Commit message guidance: keep a concise convention section.You removed the detailed conventions but still ask for “appropriate commit type.” Consider adding a short section and link (as suggested in review discussion).
Proposed snippet:
### Commit messages (short guideline) We squash-merge, so write clear, imperative messages (e.g., "Fix flaky test"). Conventional types are optional, but recommended for clarity. See a concise example in Zustand’s guide: https://github.com/pmndrs/zustand/blob/main/CONTRIBUTING.md#committingintegrations/angular-cli-20/package.json (1)
3-3: Marking package private: good — confirm TypeScript range for Angular CLI v20npm shows @angular/compiler-cli 20.0.0–20.1.7 require typescript ">=5.8 <5.9"; starting at 20.2.0 the range is ">=5.8 <6.0". If this integration uses 20.0/20.1 pin TypeScript to ~5.8.x; if it targets >=20.2 you may allow up to <6.0. Check integrations/angular-cli-20/package.json for the exact @angular/* versions and align the TypeScript devDependency accordingly.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/release.yml(2 hunks)
🔇 Additional comments (5)
.github/workflows/release.yml (5)
1-1: LGTM: Clear workflow name changeThe workflow name change from "ci" to "Release" better reflects its purpose and aligns with the introduction of changesets for release management.
14-16: LGTM: Appropriate permissions for changesets workflowThe permissions correctly include
contents: writefor pushing version commits andid-token: writefor npm publishing with OIDC, which aligns with modern secure publishing practices.
29-29: Confirmed: .nx/workflows/dynamic-changesets.yaml exists
Found .nx/workflows/dynamic-changesets.yaml with distribute-on mappings (small-changeset, medium-changeset, large-changeset); no further action required.
37-38: No action required — changeset:version script presentpackage.json defines "changeset:version" as: changeset version && pnpm install --no-frozen-lockfile && pnpm prettier:write
47-50: changeset:publish exists — verify NPM_TOKEN secretpackage.json defines "changeset:publish" -> "changeset publish" and the workflow uses NPM_TOKEN from secrets (.github/workflows/release.yml lines 47–50). Ensure the repository/GitHub Actions secret NPM_TOKEN is present and contains a valid npm token with publish permissions for the registry used.
| - name: Commit version files | ||
| run: | | ||
| git config --global user.name 'Tanner Linsley' | ||
| git config --global user.email 'tannerlinsley@users.noreply.github.com' | ||
| npm config set '//registry.npmjs.org/:_authToken' "${NPM_TOKEN}" | ||
| pnpm run cipublish | ||
| git config --global user.email 'tannerlinsley@users.noreply.github.com' git add -A | ||
| git commit -m "ci: Version Packages" | ||
| git push | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Fix git configuration and add conditional logic for version commits
The current implementation has several issues:
- Line 42 has a syntax error - missing newline between email and
git add - The commit will fail if there are no changes to commit
- No validation that version changes actually occurred
- name: Commit version files
run: |
git config --global user.name 'Tanner Linsley'
- git config --global user.email 'tannerlinsley@users.noreply.github.com' git add -A
- git commit -m "ci: Version Packages"
- git push
+ git config --global user.email 'tannerlinsley@users.noreply.github.com'
+ git add -A
+ if git diff --staged --quiet; then
+ echo "No version changes to commit"
+ else
+ git commit -m "ci: Version Packages"
+ git push
+ fi
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Commit version files | |
| run: | | |
| git config --global user.name 'Tanner Linsley' | |
| git config --global user.email 'tannerlinsley@users.noreply.github.com' | |
| npm config set '//registry.npmjs.org/:_authToken' "${NPM_TOKEN}" | |
| pnpm run cipublish | |
| git config --global user.email 'tannerlinsley@users.noreply.github.com' git add -A | |
| git commit -m "ci: Version Packages" | |
| git push | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| - name: Commit version files | |
| run: | | |
| git config --global user.name 'Tanner Linsley' | |
| git config --global user.email 'tannerlinsley@users.noreply.github.com' | |
| git add -A | |
| if git diff --staged --quiet; then | |
| echo "No version changes to commit" | |
| else | |
| git commit -m "ci: Version Packages" | |
| git push | |
| fi | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
🤖 Prompt for AI Agents
.github/workflows/release.yml around lines 39 to 46: fix the malformed git
command by placing the git add on its own line after configuring user.email, and
add conditional checks so the workflow only attempts to commit/push when version
files actually changed; implement a pre-commit check that detects changes (e.g.,
git diff --name-only or git status --porcelain) and only run git add/commit/push
if that check finds relevant files (validate by matching expected version files
or package manifests), otherwise skip committing to avoid failure when there are
no changes.
|
There is one disadvantage of using Changesets over the current setup, though I'm not sure if it's a valid point for you to consider here. With the current setup, people subscribing to GitHub releases receive a single notification/a single release on the releases page. With Changesets, however, there would be tons. A "RELEASE ALL" in the query repo would make 23 releases and send 23 notifications to subscribers.
|
🎯 Changes
As discussed on Discord (private channel): https://discord.com/channels/719702312431386674/1345158793675276319
See also: TanStack/config#218 and TanStack/virtual#946
✅ Checklist
pnpm test:pr.🚀 Release Impact
Summary by CodeRabbit
Chores
Documentation
CI