Skip to content

Upgrade vike 0.4.259-commit-2fe6cc7 -> 0.4.267-commit-5676e14 - #100

Open
dajinchu wants to merge 1 commit into
masterfrom
dc/upgrade-vike-0.4.267-commit-5676e14
Open

dajinchu wants to merge 1 commit into
masterfrom
dc/upgrade-vike-0.4.267-commit-5676e14

Conversation

@dajinchu

@dajinchu dajinchu commented Oct 6, 2026

Copy link
Copy Markdown
Collaborator

Upgrades vike to 0.4.267-commit-5676e14, the prerelease with vikejs/vike#3576. Before that fix, every renderPage() iterated over one infinite-loop tracker per request of the last 5 seconds, so the CPU cost per request grew with traffic.

Changes

  • vike 0.4.259-commit-2fe6cc7 → 0.4.267-commit-5676e14.
  • Vite 6 → 8, because this vike requires Vite 7.1+ (fix: require Vite 7.1 or above vikejs/vike#3565). AlignableWeb is already on Vite 8.
  • @vitejs/plugin-react 4 → 6, as in AlignableWeb.
  • TypeScript 5.3 → 5.9, because plugin-react's type declarations (5.2+ and 6) need TypeScript 5.6+. TypeScript 5.9 now types Map.keys().next().value as possibly undefined, so lruCache.ts gets a !.
  • Test app tsconfig.json: "moduleResolution": "Bundler". Vite 8 publishes its types only through exports, which "Node" resolution doesn't read.
  • One vike and one Vite for every workspace. On master, bifrost-fastify resolves a stale vike 0.4.255 hoisted at the root, so renderPage doesn't run on the vike we pin. This pins vike and vite at the root with overrides, the same fix as in Render wrapped pages with a single renderPage #99. Whichever PR merges second will have a small conflict in package.json.

Performance

These numbers come from #99's server benchmark (tests/bench, c=10, Apple M1 Pro), because the benchmark isn't on master yet. CPU per request, before and after run back to back:

scenario before after Δ
wrapped 2.330 ms 2.095 ms −10.1%
wrapped client navigation 1.080 ms 0.507 ms −53.0%
passthru 1.049 ms 0.558 ms −46.8%
native 5.334 ms 5.399 ms +1.2%
native client navigation 2.284 ms 2.307 ms +1.0%

Native pages don't improve. vike's new streamed pageContext values (since 0.4.267) add a check on every serialized value, which costs about as much as the fix saves on pages with a large pageContext. Patching only the fix into the current vike gave −4.6% and −10.0% on those two scenarios.

Testing

  • npm run build and the test app build pass on Node 22.21.1 and 20.19.5.
  • The e2e suite passes on both Node versions: 300 passed, 3 skipped, no retries.
  • The bifrost-fastify unit tests pass.

🤖 Generated with Claude Code

Brings in vike#3576, which stops catchInfiniteLoop() from scanning
every request of the last 5 seconds on each renderPage().

This vike requires Vite 7.1+, so Vite moves to 8 (what AlignableWeb
uses), @vitejs/plugin-react to 6, and TypeScript to 5.9: plugin-react's
type declarations need TypeScript 5.6+. TypeScript 5.9 types
Map.keys().next().value as possibly undefined, and Vite 8 publishes its
types only through `exports`, which the test app's tsconfig now reads
with "moduleResolution": "Bundler".

bifrost-fastify resolved a stale vike 0.4.255 hoisted at the root, so
renderPage didn't run on the upgraded vike. Pin vike and vite at the
root and override them so every workspace shares one copy.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant