tbenandClaude Opus 5.5
4d4a79a6dd
Client-only edits are sent to the browser right after the hydration build, without re-running server functions; SSR rebuilds afterwards and props are re-fetched only when a .server.ts output changed or after fullRebuild. Page requests wait for an in-flight SSR rebuild. The SSR build no longer runs Tailwind, the PostCSS processor is reused across rebuilds, and the watcher debounce drops from 200ms to 50ms. Co-Authored-By: Claude Opus 5.5 <[email protected]>
24 lines
939 B
TypeScript
24 lines
939 B
TypeScript
type RebuildParams = {
|
|
/**
|
|
* Force a context recreation even when the entry set is unchanged.
|
|
* Used by `fullRebuild` after it disposed the contexts.
|
|
*/
|
|
force?: boolean;
|
|
};
|
|
/**
|
|
* Single-flight SSR rebuild. Concurrent callers (each successful hydration
|
|
* rebuild triggers this, plus watcher/structural paths) join the in-flight
|
|
* rebuild instead of spawning overlapping esbuild builds.
|
|
*
|
|
* A fresh content change that lands while a rebuild is in flight is picked
|
|
* up by the next hydration rebuild cycle (each watcher event re-runs the
|
|
* hydration context rebuild, which re-enters this queue).
|
|
*/
|
|
export default function enqueueSSRRebuild(params?: RebuildParams): Promise<void>;
|
|
/**
|
|
* Resolves once the in-flight SSR rebuild (if any) has finished. Lets page
|
|
* requests avoid rendering stale SSR modules against a newer client bundle.
|
|
*/
|
|
export declare function awaitSSRRebuild(): Promise<void>;
|
|
export {};
|