Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Changesets-based release tooling: new Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Repo as GitHub Repo
participant GA as GitHub Actions
participant CS as Changesets (cli)
participant Reg as Package Registry
Dev->>Repo: push to `main` or `*-pre`/`*-maint`
Repo->>GA: trigger release workflow
GA->>CS: run `changeset version`
CS-->>GA: outputs versioned files (uncommitted)
GA->>Repo: git add/commit & push version changes
GA-->>CS: if committed == true, run `changeset publish`
CS->>Reg: publish packages
CS-->>GA: return publish results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
View your CI Pipeline Execution ↗ for commit 6adae15
☁️ Nx Cloud last updated this comment at |
Bundle Size Benchmarks
Trend sparkline is historical gzip bytes ending with this PR measurement; lower is better. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Line 5: The branch filter in the workflow (the branches: entry) doesn't match
the documented prerelease flow — update the branches pattern in
.github/workflows/release.yml so pushes to feature release branches like
"solid-v2" will trigger the job; for example, replace or augment branches:
[main, '*-alpha', '*-beta', '*-rc'] with a pattern that includes release
branches (e.g., 'solid-v*' or 'solid-*' and/or explicit branch names used in
your flow) or alternatively update the workflow docs to state that prerelease
branches must include the -alpha/-beta/-rc suffix; ensure the changed branches
value reflects whichever convention you choose so the release job runs for the
intended branch names.
- Around line 39-53: Replace the mutable action refs with their immutable commit
SHAs: update uses: changesets/action@v1.5.3 to the full commit SHA for that
changesets/action release and update uses:
tanstack/config/.github/comment-on-release@main to the specific commit SHA from
the tanstack/config repo; ensure both steps (the "Run Changesets (version or
publish)" step with id changesets and the "Comment on PRs about release" step)
use those SHAs and add Dependabot configuration to bump these SHAs in the future
rather than relying on branch or semver tags.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ab234b4f-244a-48f6-a4db-c684a4c7bb48
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
.changeset/README.md.changeset/config.json.github/workflows/release.ymlpackage.jsonscripts/publish.js
💤 Files with no reviewable changes (1)
- scripts/publish.js
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/release.yml (2)
41-42:⚠️ Potential issue | 🟠 MajorPin the publishing actions to immutable SHAs.
Both release-path actions still use movable refs (
changesets/action@v1.5.3andtanstack/config/.github/comment-on-release@main). In a job that versions and publishes packages with write permissions, these should be pinned to full commit SHAs.#!/bin/bash # Resolve the immutable SHAs behind the refs currently used in this workflow. # Expected: one SHA for changesets/action v1.5.3 and one SHA for tanstack/config main. git ls-remote https://github.com/changesets/action refs/tags/v1.5.3 git ls-remote https://github.com/tanstack/config refs/heads/mainAlso applies to: 51-51
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 41 - 42, The workflow pins actions to mutable refs (changesets/action@v1.5.3 and tanstack/config/.github/comment-on-release@main); replace both with their immutable commit SHAs by resolving the current SHA (e.g., via git ls-remote for changesets/action refs/tags/v1.5.3 and for tanstack/config refs/heads/main) and update the workflow uses entries to changesets/action@<full-sha> and tanstack/config/.github/comment-on-release@<full-sha> (ensure you update both occurrences).
5-5:⚠️ Potential issue | 🟠 MajorTrigger pattern still misses the documented prerelease branches.
This workflow now only runs on
mainand branches ending in-pre, so the PR’s documentedsolid-v2prerelease flow still would not execute. Either expand the branch matcher to cover the actual release-branch naming scheme or update the docs to require the-presuffix.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml at line 5, The workflow's branches trigger only matches main and '*-pre' and therefore misses the documented prerelease branches (e.g., solid-v2); update the workflow trigger by widening the branches matcher under the "branches:" key to include the actual prerelease naming scheme (for example add patterns like 'solid-*' or 'solid-v*' alongside 'main' and '*-pre'), or else align docs by requiring the '-pre' suffix—modify the branches array in .github/workflows/release.yml accordingly so the intended prerelease branches are matched.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 41-42: The workflow pins actions to mutable refs
(changesets/action@v1.5.3 and tanstack/config/.github/comment-on-release@main);
replace both with their immutable commit SHAs by resolving the current SHA
(e.g., via git ls-remote for changesets/action refs/tags/v1.5.3 and for
tanstack/config refs/heads/main) and update the workflow uses entries to
changesets/action@<full-sha> and
tanstack/config/.github/comment-on-release@<full-sha> (ensure you update both
occurrences).
- Line 5: The workflow's branches trigger only matches main and '*-pre' and
therefore misses the documented prerelease branches (e.g., solid-v2); update the
workflow trigger by widening the branches matcher under the "branches:" key to
include the actual prerelease naming scheme (for example add patterns like
'solid-*' or 'solid-v*' alongside 'main' and '*-pre'), or else align docs by
requiring the '-pre' suffix—modify the branches array in
.github/workflows/release.yml accordingly so the intended prerelease branches
are matched.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ac44de3b-fb2a-434c-a54c-8be7e0a71b97
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 43-46: The current check uses pnpm run changeset:publish and greps
for "published" against publish-output.txt, which false-positives and writes the
log into the repo; update the step that runs pnpm run changeset:publish so it
writes its output to a temp file in $RUNNER_TEMP (e.g.,
$RUNNER_TEMP/publish-output.txt) and change the grep to match the exact success
phrase (e.g., "packages published successfully") before setting the
GITHUB_OUTPUT variable; ensure subsequent steps (like the later git add .) do
not reference or stage the temp file.
- Around line 39-55: The workflow publishes packages before persisting version
changes and uses a fragile grep + commits everything; reorder to run the "Commit
and Push Version Changes" step immediately after "Version Packages" (i.e., after
running pnpm run changeset:version) to commit only the changeset/version files
(avoid git add . and exclude publish-output.txt), then run pnpm run
changeset:publish and detect success via its exit code instead of grepping
publish-output.txt; alternatively replace the sequence with the official
Changesets GitHub Action to atomically version+publish. Also, if prerelease
branches are intended, add an explicit pnpm run changeset:pre (or changeset pre
enter) when branch name matches *-pre to enable prerelease mode before
versioning/publishing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8fe4b2af-080e-4bf1-8da5-02d9842b6b7b
📒 Files selected for processing (1)
.github/workflows/release.yml
.github/workflows/release.yml
Outdated
| run: | | ||
| git config --global user.name 'Tanner Linsley' | ||
| git config --global user.email 'tannerlinsley@users.noreply.github.com' | ||
| pnpm run cipublish | ||
| pnpm run changeset:publish 2>&1 | tee publish-output.txt | ||
| if grep -q "published" publish-output.txt; then | ||
| echo "published=true" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat .github/workflows/release.ymlRepository: TanStack/router
Length of output: 1736
🌐 Web query:
changeset:publish output success message format
💡 Result:
For @changesets/cli, when changeset publish successfully publishes at least one package, the success output format is:
packages published successfully:
<packageName1>@<newVersion1>
<packageName2>@<newVersion2>
...
(Those <packageName>@<newVersion> lines are printed one-per-line.)[1]
If git tagging is enabled (default), it then prints:
Creating git tag... # or "Creating git tags..." if >1 package
New tag: <packageName>@<newVersion> # for each published package (or "v<newVersion>" in root-mode)
```[1]
**Sources:**
[1] Changesets publish command implementation (`packages/cli/src/commands/publish/index.ts`). ([github.com](https://github.com/changesets/changesets/blob/main/packages/cli/src/commands/publish/index.ts))
Citations:
- 1: https://github.com/changesets/changesets/blob/main/packages/cli/src/commands/publish/index.ts
---
🌐 Web query:
`changesets publish no-op nothing to publish output message`
💡 Result:
In **Changesets**, `changeset publish` becomes a no-op when it finds nothing new to publish (i.e., no packages with a local version that isn’t already on the registry). In that case it logs this warning message:
- `No unpublished projects to publish` [1]
…and then finishes without publishing anything (it does **not** treat this as an error). [1]
**Sources**
[1] Changesets CLI `publish` command implementation (`packages/cli/src/commands/publish/index.ts`) ([raw.githubusercontent.com](https://raw.githubusercontent.com/changesets/changesets/9657b268d44645f7b55dcd6724578e0438415e95/packages/cli/src/commands/publish/index.ts))
Citations:
- 1: https://raw.githubusercontent.com/changesets/changesets/9657b268d44645f7b55dcd6724578e0438415e95/packages/cli/src/commands/publish/index.ts
---
</details>
**The grep pattern for detecting successful publishes can false-positive when nothing is published.**
`grep -q "published"` will match both `"packages published successfully:"` (success) and `"No unpublished projects to publish"` (no-op), causing a no-op `changeset:publish` run to incorrectly set `published=true`. Additionally, the log file written to the repo root (`publish-output.txt`) gets staged by the subsequent `git add .` on line 53, polluting the commit.
Use a more specific match pattern like `"packages published successfully"` and write the log to `$RUNNER_TEMP` to avoid both the false-positive and repo pollution.
<details>
<summary>Suggested approach</summary>
```diff
- pnpm run changeset:publish 2>&1 | tee publish-output.txt
- if grep -q "published" publish-output.txt; then
+ output_file="$RUNNER_TEMP/publish-output.txt"
+ pnpm run changeset:publish 2>&1 | tee "$output_file"
+ if grep -q "packages published successfully" "$output_file"; then
echo "published=true" >> "$GITHUB_OUTPUT"
fi
📝 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.
| run: | | |
| git config --global user.name 'Tanner Linsley' | |
| git config --global user.email 'tannerlinsley@users.noreply.github.com' | |
| pnpm run cipublish | |
| pnpm run changeset:publish 2>&1 | tee publish-output.txt | |
| if grep -q "published" publish-output.txt; then | |
| echo "published=true" >> "$GITHUB_OUTPUT" | |
| run: | | |
| output_file="$RUNNER_TEMP/publish-output.txt" | |
| pnpm run changeset:publish 2>&1 | tee "$output_file" | |
| if grep -q "packages published successfully" "$output_file"; then | |
| echo "published=true" >> "$GITHUB_OUTPUT" | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml around lines 43 - 46, The current check uses
pnpm run changeset:publish and greps for "published" against publish-output.txt,
which false-positives and writes the log into the repo; update the step that
runs pnpm run changeset:publish so it writes its output to a temp file in
$RUNNER_TEMP (e.g., $RUNNER_TEMP/publish-output.txt) and change the grep to
match the exact success phrase (e.g., "packages published successfully") before
setting the GITHUB_OUTPUT variable; ensure subsequent steps (like the later git
add .) do not reference or stage the temp file.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
46-46: Consider more targeted staging instead ofgit add .Using
git add .stages everything in the working directory. While typically safe in a clean CI checkout, explicitly staging only the files modified bychangeset:version(package.json files, CHANGELOGs, and.changeset/directory) would be more predictable.♻️ More targeted staging
- git add . + git add "**/package.json" "**/CHANGELOG.md" ".changeset/"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml at line 46, Replace the broad "git add ." step with a targeted add that only stages files updated by the changeset:version action (e.g. package.json files, CHANGELOG.md files, and files under the .changeset/ directory); update the workflow to run a targeted git add for "**/package.json", "**/CHANGELOG.md" and ".changeset/**" (or compute the list of changed files from git output) instead of adding the entire working tree so only the intended versioning files are committed.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release.yml:
- Line 46: Replace the broad "git add ." step with a targeted add that only
stages files updated by the changeset:version action (e.g. package.json files,
CHANGELOG.md files, and files under the .changeset/ directory); update the
workflow to run a targeted git add for "**/package.json", "**/CHANGELOG.md" and
".changeset/**" (or compute the list of changed files from git output) instead
of adding the entire working tree so only the intended versioning files are
committed.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 272d9ab1-9ff6-418b-9a4a-d2f8252ed523
📒 Files selected for processing (1)
.github/workflows/release.yml
SeanCassiere
left a comment
SeanCassiere
left a comment
There was a problem hiding this comment.
Definitely a fan of not having to go through the Versions PR workflow.
I'm not sure I fully understand why the alpha and beta branches are being removed in favor of *-pre. I'm not opposed to it, just don't fully understand it.
The current workflow is, whilst the main branch is active, you create/merge into alpha/beta and only commit "essential" items into main. Then once alpha is done, sync up and bring alpha back into main.
Also, once you are done with the current major, you store a copy of the branch using a different name. So when Router begins active dev on v2, what'll happen is that a copy of main will be stored as v1 and then main will be renamed to alpha while dev does gone. Eventually as its ready for launch alpha gets named as main.
Outside of current dev workflow, it is also how the docs website is designed to handle the fetching of documentation. So when you switch the version to "v7", "latest" -> "main", "alpha", in SSR, its changing the target branch from which docs are pulled.
|
@SeanCassiere the problem with If you look at tanstack query, the svelte-query is at v6, while vue/react/solid-query are still on v5 - this is possible due to changesets. Similarly, there's a wish to start pre-releasing and before too long stable releasing a v2 of the solid-router, likely ahead of the react-router having a major. The flow here suggest to make e.g. a |
SeanCassiere
left a comment
SeanCassiere
left a comment
There was a problem hiding this comment.
@birkskyum makes sense 👍🏼
Just want to make sure the workflow is solidified. Also, ofc, the documentation side of things, since the website has certain limitations on that front.
For that second scenario, we'd then have a storage branch named v1 - and have the main active branch targeting v2 be something like v2-pre right?
|
The idea here is that we always would cut stable releases from
and then when we want to go beta we run
Before merging in |
Yup clear on this part. My thinking is more along the lines of TanStack Router v1 -> v2. Not just the individual framework packages, rather when Router as a whole - does its v2 changes. For example, what Table is going doing at the moment in its v8 to v9 move, with alpha containing the current v9 code + docs till that gets promoted. Either way, that's a ways away, so we can change things to fit the requirements of the website as needed. Nothing blocking, just clarifying on workflow. Edit: or simply, I'm possibly just over-thinking things 😅. either ways, a 👍🏼 from me. |
…id-router-v1-maint`
|
I have added the |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 41-55: The commit-and-push step (step id "commit") can re-trigger
and cancel the running workflow; change the commit command to include a CI-skip
token so the push won't start a new run (e.g., use git commit -m "ci: release
[skip ci]" or "ci: release [ci skip]") so that the subsequent Publish Packages
step (pnpm run changeset:publish) sees committed=true and runs; update the
commit message used in the git commit invocation inside the "Commit and Push
Version Changes" step accordingly.
- Around line 53-55: The "Publish Packages" step currently runs "pnpm run
changeset:publish" without a dist-tag; update that step so publishing from
maintenance or pre-release branches sets an explicit dist-tag or enables
changeset pre-mode. Modify the "Publish Packages" run command (or the script it
invokes) to detect the branch name (e.g. from GITHUB_REF) and either call
changeset publish --tag <branch-derived-tag> for "*-maint" and "*-pre" branches
or enable --pre/CHANGESET_PRE when on pre-release branches; ensure the step name
"Publish Packages" and the invoked command "pnpm run changeset:publish" are
updated accordingly so the correct dist-tag is passed to changeset publish.
- Around line 53-55: The "Publish Packages" GitHub Actions step (named "Publish
Packages") runs the pnpm run changeset:publish command which creates git tags
locally but no subsequent push, so ensure tags are propagated: either modify the
step to run a follow-up git push --follow-tags after pnpm run changeset:publish,
or change the publish invocation to disable tag creation by passing the no-tag
flag (e.g., call the underlying changeset publish with --no-git-tag via pnpm run
changeset:publish or adjusting the script that pnpm run changeset:publish
resolves to). Make sure the chosen approach references the existing "Publish
Packages" step and the pnpm run changeset:publish command so the workflow will
either push created tags or avoid creating them.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0d697501-d48e-4fb1-b2bb-9295a01a2029
📒 Files selected for processing (1)
.github/workflows/release.yml
2 participants
Move router repo to changesets, same as tanstack query/devtools/ai/form/db/store etc.
Changes
scripts/publish.js.changeset/config.json*-prebranch support for pre-releases (publishes withnextdist-tag)*-maintbranch support for maintaining old majors (publishes withmaintdist-tag)Release flow going forward
<package>-prebranches (e.g.solid-router-pre) usingchangeset pre enter beta<package>-v<N>-maintbranches (e.g.solid-router-v1-maint)router-coreautomatically patch-bumps all packages that depend on it and publishes them too:router-core1.2.0 → 1.3.0 (minor, from changeset)react-router1.5.0 → 1.5.1 (auto patch bump)solid-router1.3.0 → 1.3.1 (auto patch bump)This lets packages version independently. For a pre-release like solid-router v2, we'd do that from a
solid-router-prebranch, and then when it's ready merge it to main. The old v1 can continue receiving patches fromsolid-router-v1-maint.Summary by CodeRabbit