chore(deps): vite-plus sync - #3244
Conversation
Signed-off-by: Adam Setch <adam.setch@outlook.com>
| persist-credentials: false | ||
|
|
||
| - name: Setup Node.js | ||
| uses: ./.github/actions/setup-node |
There was a problem hiding this comment.
this breaks our actionlint step
| persist-credentials: true | ||
|
|
||
| - name: Setup Node.js | ||
| uses: ./.github/actions/setup-node |
There was a problem hiding this comment.
this breaks our actionlint step
… 0.3.0 - renovate-vite-migrate.yml: route github.event.pull_request.head.ref through an env var instead of interpolating it directly in a run: script (actionlint/zizmor script-injection finding) - renovate-vite-migrate.yml, lint.yml: use GitHub's self-repository uses: $/... syntax instead of ./... for the local setup-node action (zizmor self-repository finding) - AvatarWithFallback.tsx: oxlint 1.79.0 (bundled by vite-plus 0.3.0) now flags react(static-components) for selecting an icon component via a function call and rendering it as a dynamic JSX tag. Replaced with a small statically-declared component that renders a literal JSX element per userType branch. - SystemSettings.tsx: oxlint now flags react(set-state-in-effect) for resetting liveModifierAccelerator synchronously inside an effect. Reset it at the point recording starts (the button's onClick) instead of synchronizing it via an effect. Signed-off-by: Adam Setch <adam.setch@outlook.com>
…ort $/ yet zizmor recommends GitHub's new self-repository uses: $/... syntax (added July 2026), but the actionlint:1.7.12 container pinned in .github/workflows/lint.yml predates it and errors with 'invalid format because ref is missing'. actionlint is a required status check; zizmor is advisory only (not in branch protection's required list), so keep ./ for now. Revisit once actionlint's pin is upgraded to a version that recognizes $/. Signed-off-by: Adam Setch <adam.setch@outlook.com>
|
afonsojramos
left a comment
There was a problem hiding this comment.
Thanks for digging into this. Seeing how much tooling is needed to keep Vite+ and its underlying dependencies aligned, I’d rather remove Vite+ and use Vite, Vitest, Oxlint, and Oxfmt directly. I don’t think the unified CLI provides enough value to justify the added coupling and maintenance. Happy to discuss tho!
I tend to agree... It's headscratching that this is how vite-plus handles optional deps. Maybe once it hits v1 it'll have a better solution... I have one final play in motion - having If that turns out to be a dead end, let's pivot |



Why
vite-plus,vite,vitest, and the@vitest/*family are version-coupled —vite-plusbundles/targets a specificvite/vitestrelease internally, and this project depends on the same real packages directly.When they drift apart, pnpm loads two different
vitestcopies into the test workers, breaking everyrejects/.resolves.toThrow()assertion.This has already happened once on
main(#3215, 152 test failures) and was narrowly avoided twice more by hand (#3224, #3226-era fix).Two open Renovate PRs today — #3237 (
@vitest/*→ 4.1.11) and #3240 (vite-plus→ 0.3.0) — could each merge independently and reproduce it a fourth time.Supersedes #3237 and #3240.
What Changes
vp migrate, which went further than a manual fix would have: it aliasedviteandvite-plusthemselves to catalog references (not just@vitest/browser-playwright/@vitest/coverage-v8), making the pnpm catalog the single source of truth for the whole toolchain.renovate.json— groupedvite-plus+vite+vitest+@vitest/**into onepackageRulesentry (same pattern as the existing@octokit/**group) so Renovate can never split them across PRs again. AddedgitIgnoredAuthorsfor the new automation's commit identity..github/workflows/renovate-vite-migrate.yml) — runsvp migrate --no-interactiveon Renovate's grouped PR branch and pushes back any reconciliation, before human review. Triggers on changed dependency files rather than branch name (Renovate's grouped branch naming isn't confirmed yet).vite-toolchain-driftinlint.yml) — fails ifvp migratewould produce a diff, catching drift from any source (Renovate or manual edit). Advisory only for now — not yet in required status checks, promote once proven stable across a few real PRs.CONTRIBUTING.md— documented the coupling and why Mend'spostUpgradeTasks/allowedCommands(the "native" alternative to the new workflow) wasn't pursued: it's a global, Mend-admin-only setting requiring an out-of-band request.