🍕 vite: preload view-mode startup graph + on-page component chunks#255
Open
jjpaulino wants to merge 1 commit into
Open
🍕 vite: preload view-mode startup graph + on-page component chunks#255jjpaulino wants to merge 1 commit into
jjpaulino wants to merge 1 commit into
Conversation
The Vite view bootstrap mounts components by scanning the DOM and import()-ing each component's client.js at runtime. Those dynamic chunks aren't referenced by any tag in the server-rendered HTML, so the browser can't start fetching a component's client (nav, header, …) or its deps (auth, gtm, shared chunks) until the deferred bootstrap has downloaded, executed, and called import() — a load waterfall that visibly delays JS-gated UI like the global nav. - buildManifest now keys dynamic entries (components/<name>/client, layouts/<name>/client), not just the bootstrap/kiln entries, so the server can look up a page's component chunks. - getViteModulePreloads now returns the bootstrap PLUS its static import chunks (globals-init, env-init, shared chunks) so the whole synchronous startup graph is preloaded during HTML parse. - new getComponentPreloads(names, assetPath) returns each component's client chunk + static imports (de-duped) for the server to merge into media.modulePreloads. Consumed by nymag/sites resolve-media.js (stacked PR). Docs: CLAY-VITE.md §4d. Tests: lib/cmd/vite/index.test.js, lib/cmd/vite/scripts.test.js. Co-authored-by: Cursor <cursoragent@cursor.com>
|
coverage: 87.13% (+0.05%) from 87.084% — jordan/vite-modulepreload into master |
Member
Author
|
Paired consumer PR (the |
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
2 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.
What does this PR do?
Makes the Vite view-mode pipeline emit the manifest data the server needs to preload the JavaScript that gates first paint of interactive UI — most visibly the global nav — instead of discovering it via a runtime
import()waterfall.TL;DR — for reviewers short on time
Review in this order (foundational → consumer-facing → mechanical):
buildManifest/isManifestChunkinlib/cmd/vite/scripts.js. This is the core change:components/<name>/clientandlayouts/<name>/clientchunks are now discoverable in_manifest.json, not just the bootstrap/kiln entries.getViteModulePreloadsinlib/cmd/vite/index.jsnow returns the bootstrap plus its static imports (globals-init, env-init, shared chunks).getComponentPreloadsinlib/cmd/vite/index.js(new export) returns each on-page component's client chunk + static imports, de-duped, for the server to merge intomedia.modulePreloads.entryUrls/makeRebase(mechanical — extracted to keep the two resolvers under the complexity budget).CLAY-VITE.md§4d,index.test.js,scripts.test.js.Risk: low. Additive — new manifest keys + a new export.
resolveModuleScripts/existing callers are unchanged, andgetComponentPreloadsis guarded on the consumer side. No behavior change for Browserify sites.If you only review one thing:
isManifestChunk/buildManifest— confirm only entry + dynamic-entry chunks get keyed and shared/vendor chunks stay reachable viaimports[].Why are we doing this? Any context or related work?
On Vite sites the global nav presents noticeably slower than on Browserify sites. Root cause is a module load waterfall: the view bootstrap is deferred, and it mounts components by scanning the DOM and
import()-ing each component'sclient.jsat runtime. Those dynamic chunks are referenced by no tag in the server-rendered HTML, so the browser can't begin fetchingglobal-nav/client.js(or its deps — auth, gtm, shared chunks) until the bootstrap has downloaded, parsed, executed, and calledimport(). Browserify, by contrast, ships that code in large eagerly-executed bundles, so the nav is wired up as soon as the bundle runs.amphora-htmlalready supports<link rel="modulepreload">(andnymag/sitesenables it), but today ClayCLI only ever preloads the bootstrap file itself — not its static imports, and not the per-page component chunks. This PR closes that gap on the ClayCLI/manifest side.Stacked with the
nymag/sitesconsumer PR, which mergesgetComponentPreloads(...)output intomedia.modulePreloadsinresolve-media.js(guarded so older ClayCLI versions without the helper are a no-op). Cross-link added there.Where should a reviewer start?
buildManifestinlib/cmd/vite/scripts.js— everything else builds on the enriched manifest.Manual testing steps?
clay compile --vite(or the split view/edit build) on a site and open.clay/public/js/_manifest.json.components/<name>/clientkeys (e.g.components/global-nav/client) each with afile+imports[], in addition tovite-bootstrapand the kiln entry.getComponentPreloads(['global-nav'], assetPath)returns the nav client chunk + its static imports, andgetViteModulePreloads(assetPath)returns the bootstrap + globals-init/env-init/shared chunks.<link rel="modulepreload">tags appear in<head>for those URLs and the nav paints without waiting on a coldimport()round-trip.Screenshots
n/a (build/runtime manifest change).
Additional Context
CLAY-VITE.md§4d "Module preloading & the on-demand component waterfall".lib/cmd/vite/index.test.js(getViteModulePreloads startup graph + fullgetComponentPreloadssuite),lib/cmd/vite/scripts.test.js(dynamic entry keyed, shared chunk not keyed). Fulllib/cmd/vitejest suite green; reponpm run lintclean.Made with Cursor