test(vite-tests): track the latest rolldown-canary rebased onto vite main#10318
Merged
graphite-app[bot] merged 1 commit intoJul 17, 2026
Conversation
shulaoda
marked this pull request as ready for review
July 16, 2026 14:39
Member
Author
How to use the Graphite Merge QueueAdd the label graphite: merge-when-ready to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
✅ Deploy Preview for rolldown-rs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Member
|
We should unify the repo at the root of the workspace and use |
Member
Author
I’ll open a PR on top of the stack to fix it. |
h-a-n-a
approved these changes
Jul 17, 2026
Contributor
Merge activity
|
…main (#10318) ## Problem Since #10164 (and #10293 which unified the checkouts), `packages/vite-tests/run.ts` ran Vite's test suite on the commit pinned by the vite submodule gitlink. The `rolldown-canary` branch of vitejs/vite is regularly rebased and force-pushed, so any pinned commit rots quickly: the current pin `4d1480ca` is no longer on any branch. Worse, test adjustments landing on `rolldown-canary` cannot reach rolldown CI without a manual pin bump. That is exactly why CI on `main` is red right now: the `js-sourcemap` inline snapshot was updated on `rolldown-canary` on 2026-07-15 (for the output change from #10249), but the pin predates that update. ## Change Restore the pre-#10164 approach from #7633. `run.ts` now does: ``` git clone --branch rolldown-canary https://github.com/vitejs/vite.git git rebase origin/main ``` so test adjustments landing on `rolldown-canary` take effect right away, and new tests from Vite `main` surface incompatibilities with rolldown early. The rebase identity comes from the existing "Configure Git" step in the vite-test CI jobs. All inline spec patches are removed from `run.ts`. Test adjustments belong on the `rolldown-canary` branch itself, not in a patch layer inside this repo: - The `css-codesplit` style-/style2- patch was already dead code: upstream Vite `main` has had the swapped assertions since vitejs/vite#22922. - The `assets` raw-query skip (#8839) is obsolete: the test passes on current rolldown `main`, in both serve and build. - The `hmr-full-bundle-mode` invalidate patch is removed. This one still needs a spec fix on `rolldown-canary`: with client-side HMR there is no "hmr invalidate" server log anymore, so the spec should assert that `.invalidation-parent` becomes `child updated` instead. Until that lands on the canary branch, `test-serve` fails this single test. Also reverts the `tsconfig.json` include added for the now-removed `checkout.ts` import, and updates the `repo-structure.md` description. ## Verification Full local run against current rolldown `main` (debug build): | Suite | Result | | --- | --- | | test-unit | 65 files passed | | test-serve | 1 real failure: `hmr-full-bundle-mode > invalidate` (expected, see above) | | test-build | 93 files passed, `js-sourcemap` snapshot green again | `environment-react-ssr > deps reload` failed once under full-suite load but passes in isolation (timing flake with the slow debug binding, not a regression). <!-- - What is this PR solving? Write a clear and concise description. - Reference the issues it solves (e.g. `fixes #123`). - What other alternatives have you explored? - Are there any parts you think require more attention from reviewers? Also, please make sure you do the following: - Read the Contributing Guidelines at https://rolldown.rs/contribution-guide/. - Check that there isn't already a PR that solves the problem the same way. If you find a duplicate, please help us review it. - Update the corresponding documentation if needed. - Include relevant tests that fail without this PR but pass with it. If the tests are not included, explain why. Thank you for contributing to Rolldown! -->
graphite-app
Bot
force-pushed
the
07-16-test_vite-tests_track_the_latest_rolldown-canary_rebased_onto_vite_main
branch
from
July 17, 2026 04:25
9db3bd7 to
479f45d
Compare
graphite-app Bot
pushed a commit
that referenced
this pull request
Jul 17, 2026
Follow-up to the review comments on #10318 and #10319: both test projects should be set up from the single `vite/` checkout at the workspace root, via the `just setup-vite` checkout step. ## Change `packages/vite-tests/run.ts` no longer clones vitejs/vite from GitHub on its own. It now: 1. calls `ensureViteCheckout()` from `scripts/src/setup-vite/checkout.ts` (the checkout step of `just setup-vite`), which guarantees the root `vite/` checkout exists and is at the latest `rolldown-canary` rebased onto the latest `main`, exactly what #10319 set up for the dev-server tests. 2. clones that checkout locally into `./repo` and runs Vite's test suite there. The local clone shares objects via hardlinks, so no extra network download. It stays a throwaway copy because this suite must edit tracked files (rewrite the pnpm overrides to point `rolldown` at the workspace package, which also rewrites the lockfile on install), while `vite/` itself must stay unpatched: the dev-server setup installs it with `--frozen-lockfile` and builds it with Vite's own pinned rolldown, so the two harnesses would corrupt each other's state if they shared one working copy. Both harnesses therefore run on exactly the same Vite code: one checkout, one rebase result, no chance of the two suites drifting apart because `rolldown-canary` or `main` moved between two independent clones. Per the review discussion on #10319, an existing checkout is kept up to date as well: when it is clean and on `rolldown-canary` (the managed state), every setup fetches and re-derives the latest `rolldown-canary` rebased onto `main` (kept as-is when the fetch fails, e.g. offline). A checkout taken over by the developer (dirty, or switched to another branch) is used exactly as-is, with a notice, so local experiments inside `vite/` are never trampled and can still be tested through both harnesses. Also restores the `checkout.ts` include in `packages/vite-tests/tsconfig.json` and updates the docs accordingly. ## Verification - Local smoke run: `run.ts` picks up the shared checkout, clones it locally, and proceeds through install, build, and into the test suites. - All three checkout states exercised live: a clean checkout on `rolldown-canary` was updated to the latest upstream state; a dirty checkout and a detached HEAD were left as-is with a notice. - `just lint` fully green.
graphite-app
Bot
deleted the
07-16-test_vite-tests_track_the_latest_rolldown-canary_rebased_onto_vite_main
branch
July 17, 2026 04:29
hyfdev
reviewed
Jul 17, 2026
hyfdev
left a comment
hyfdev
left a comment
Member
There was a problem hiding this comment.
Post-merge note: this layer is sound for the stated goal. Tracking tip rolldown-canary rebased onto main fixes the pin-rot problem, and dropping the local patch layer is the right place for canary-side adjustments.
The residual hmr-full-bundle-mode > invalidate failure on Vite Test Ubuntu is the known canary gap already called out in the PR body (non-required gate). Landing the canary-side assertion fix will clear it without further rolldown changes.
If this review had landed before merge, the verdict would have been Approve.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Since #10164 (and #10293 which unified the checkouts),
packages/vite-tests/run.tsran Vite's test suite on the commit pinned by the vite submodule gitlink. Therolldown-canarybranch of vitejs/vite is regularly rebased and force-pushed, so any pinned commit rots quickly: the current pin4d1480cais no longer on any branch. Worse, test adjustments landing onrolldown-canarycannot reach rolldown CI without a manual pin bump. That is exactly why CI onmainis red right now: thejs-sourcemapinline snapshot was updated onrolldown-canaryon 2026-07-15 (for the output change from #10249), but the pin predates that update.Change
Restore the pre-#10164 approach from #7633.
run.tsnow does:so test adjustments landing on
rolldown-canarytake effect right away, and new tests from Vitemainsurface incompatibilities with rolldown early. The rebase identity comes from the existing "Configure Git" step in the vite-test CI jobs.All inline spec patches are removed from
run.ts. Test adjustments belong on therolldown-canarybranch itself, not in a patch layer inside this repo:css-codesplitstyle-/style2- patch was already dead code: upstream Vitemainhas had the swapped assertions since fix(deps): update rolldown-related dependencies vitejs/vite#22922.assetsraw-query skip (Vite test failure: assets.spec.ts build watch raw query import #8839) is obsolete: the test passes on current rolldownmain, in both serve and build.hmr-full-bundle-modeinvalidate patch is removed. This one still needs a spec fix onrolldown-canary: with client-side HMR there is no "hmr invalidate" server log anymore, so the spec should assert that.invalidation-parentbecomeschild updatedinstead. Until that lands on the canary branch,test-servefails this single test.Also reverts the
tsconfig.jsoninclude added for the now-removedcheckout.tsimport, and updates therepo-structure.mddescription.Verification
Full local run against current rolldown
main(debug build):hmr-full-bundle-mode > invalidate(expected, see above)js-sourcemapsnapshot green againenvironment-react-ssr > deps reloadfailed once under full-suite load but passes in isolation (timing flake with the slow debug binding, not a regression).