@foldkit/vite-plugin weekly downloads statistics

@foldkit/vite-plugin

Vite plugin for Foldkit: view identity branding for the differ, plus state-preserving live reload.

Installation

npm install -D @foldkit/vite-plugin
# or
pnpm add -D @foldkit/vite-plugin
# or
yarn add -D @foldkit/vite-plugin

Usage

Add the plugin to your vite.config.ts:

import { defineConfig } from 'vite'

import { foldkit } from '@foldkit/vite-plugin'

export default defineConfig({
  plugins: [foldkit()],
})

View identity

Foldkit's differ tracks two independent kinds of identity: user keys, which match siblings in dynamic lists, and a framework-managed identity, which decides whether a matched position is still the same thing. When the producing view function changes, the differ replaces the node instead of patching it, so DOM state cannot bleed across an identity change. Branches rendered inline by one view function share that function's identity and patch in place, exactly as same-type elements do in React; extracting the branches into named view functions makes them identity boundaries.

This plugin supplies that identity. At build time, in dev and production alike, it wraps every function return in your application modules with a branding call that stamps returned vnodes with the function's id (module path plus function name), set-if-absent. The identity is nothing else: it ships in the client bundle, so anything derived from the module's contents would be a published check against those contents. Identity therefore attaches at view-function boundaries, and any branching syntax behaves the same: if/else, ternaries, Effect Match, switch statements, and pattern-matching libraries are all equivalent, because identity belongs to the function that produced the subtree, not to the branch that selected it.

Foldkit core modules are never instrumented, and functions that never return vnodes are wrapped inertly. Builds without this plugin fall back to positional matching plus keys, where branch points need hand-written keys.

State-preserving live reload

When you save a file during development, the plugin:

1. Preserves your application's current Model
2. Triggers a full page reload
3. Restores the preserved Model after reload

Code changes do not reset the application. Forms stay filled, counters keep their values, and games keep their positions.

How it works

The plugin uses Vite's WebSocket connection to communicate between the dev server and browser:

• On file change: The browser sends the current Model to the Vite server for preservation.
• On reload: The browser requests the preserved Model from the server and initializes the Foldkit Runtime with it.

The Model survives development reloads but clears on a manual browser refresh, so a refresh still resets the application.

Server rendering dev host

Pass ssr with the path to your server entry to render page requests through it during development:

plugins: [foldkit({ ssr: { serverEntry: '/src/entry.server.ts' } })]

With this set, the dev server converts HTML page requests to Web Request values, passes them to the entry's renderPage, and serves the returned Response. The request URL retains Vite's configured base prefix and the browser's query string. Vite continues to serve the client entry, HMR, and assets, and the server entry runs through Vite's module graph, so edits to it apply without a restart. The client side of the handoff needs no plugin configuration: a server-rendered application's client entry calls Runtime.hydrate instead of Runtime.run. Hydration adopts matching DOM, rebuilds mismatched subtrees, and refuses an invalid or cross-deployment handoff. The option shapes only the dev server; production hosts import the built server entry themselves. See the Server Rendering documentation for the full contract.

Vite retains ownership of configured proxy routes before Foldkit handles application requests. Vite's server.cors option applies to Vite-owned source modules, assets, and HMR. It does not add headers to application responses or answer their preflights. Preflight ownership follows Access-Control-Request-Method, so a preflight for an application POST reaches renderPage even when its path looks like an asset. An OPTIONS request without both Origin and Access-Control-Request-Method is not a preflight and also reaches renderPage. Define application CORS in renderPage, where development and the deployed host share one policy. Vite's allowedHosts check runs before proxy and application handling, including OPTIONS and methods the Web Request API cannot represent.

Server-rendered documents

With ssr.build, the client input is a script and the server entry produces the complete HTML document. Configure the script beside the server entry:

foldkit({
  ssr: {
    clientEntry: '/src/entry.ts',
    serverEntry: '/src/entry.server.ts',
    build: true,
  },
})

Import CSS from the client script. Export renderDocument alongside renderPage in the server entry:

export const renderDocument = Server.renderDocument

Server.renderDocument(application, assets, options) assembles the document with the application's title, language, direction, canonical URL, and Open Graph URL. assets contains the emitted entryScript, ordered stylesheets, and modulePreloads. The plugin collects static imports and their CSS, leaves lazy imports to Vite's runtime, and supplies the same assets to request-time rendering and prerendering. The default document includes UTF-8 and viewport metadata. Wrap the helper to set a default lang or add trusted author-owned head markup, such as a favicon. Never interpolate unescaped request data into head.…