Meta tags:
description=Next Generation Frontend Tooling;

Headings (most frequently used words):

ssr, server, rendering, logic, side, example, projects, source, structure, conditional, setting, up, the, dev, building, for, production, generating, preload, directives, pre, ssg, externals, specific, plugin, target, bundle,

Text of the page (most frequently used words):
the (81), ssr (58), vite (47), server (38), and (31), build (23), for (22), html (22), this (21), client (21), entry (19), you (17), can (15), will (14), dev (13), app (13), use (13), const (12), node (11), instead (11), example (11), logic (10), that (10), #render (10), also (8), using (8), plugins (8), api (8), vue (8), module (8), react (8), production (8), src (8), dist (8), your (7), plugin (7), with (7), esm (7), from (7), pre (7), require (7), rendering (7), index (7), are (6), options (6), externalized (6), commonjs (6), which (6), script (6), need (6), manifest (6), used (6), source (6), await (6), template (6), guide (6), integration (5), env (5), want (5), target (5), frameworks (5), transform (5), specific (5), support (5), conditional (5), have (5), package (5), config (5), files (5), static (5), ids (5), framework (5), middleware (5), side (5), dependencies (4), bundle (4), into (4), file (4), object (4), may (4), code (4), function (4), transforms (4), following (4), both (4), working (4), during (4), contains (4), automatically (4), only (4), routes (4), async (4), json (4), outdir (4), ssrloadmodule (4), building (4), next (4), rendered (4), express (4), application (4), level (4), backend (3), any (3), built (3), all (3), noexternal (3), some (3), setting (3), default (3), but (3), different (3), set (3), hooks (3), note (3), rollup (3), load (3), based (3), via (3), heuristics (3), likely (3), ship (3), compatible (3), builds (3), type (3), externals (3), check (3), point (3), because (3), dependency (3), provides (3), version (3), then (3), back (3), ssg (3), see (3), preload (3), directives (3), ctx (3), out (3), vitejs (3), asset (3), serving (3), middlewares (3), serve (3), links (3), should (3), scripts (3), url (3), req (3), path (3), res (3), let (3), outlet (3), hmr (3), instance (3), connect (3), createserver (3), middlewaremode (3), mode (3), own (3), main (3), structure (3), community (3), discord (3), low (3), awesome (3), variables (2), modes (2), error (2), cases (2), like (2), single (2), javascript (2), webworker (2), environment (2), web (2), worker (2), packages (2), not (2), these (2), additional (2), future (2), perform (2), svelte (2), components (2), aliases (2), actual (2), make (2), project (2), import (2), dom (2), its (2), many (2), when (2), running (2), speed (2), efficient (2), same (2), site (2), demo (2), read (2), exported (2), provide (2), full (2), now (2), were (2), rendertostring (2), supports (2), associated (2), generate (2), ssrmanifest (2), flag (2), generating (2), branches (2), add (2), produce (2), directly (2), apphtml (2), end (2), apis (2), assumes (2), bundling (2), here (2), createviteserver (2), https (2), control (2), create (2), replaced (2), placeholder (2), div (2), reference (2), projects (2), experimental (2), github (2), 日本語 (2), 简体中文 (2), english (2), languages (2), changelog (2), compat (2), chat (2), twitter (2), suggest, changes, page, throw, ins, imported, treat, runtimes, might, enable, behavior, two, things, true, run, resolution, each, platform, configure, before, was, informed, positional, param, major, updated, find, outdated, posts, previous, optional, currently, extend, metadata, name, return, myssrplugin, export, resolveid, such, compiles, formats, passes, property, configured, redirects, one, another, alias, work, aliasing, prefix, npm, pnpm, yarn, node_modules, improve, detect, has, enabled, externalize, importing, them, dynamic, leads, errors, manually, adjust, external, otherwise, whether, valid, syntax, specifies, format, resolved, probably, ships, performs, automated, externalization, system, pulling, bundled, transforming, more, simply, greatly, improves, data, needed, certain, known, ahead, time, considered, form, generation, branch, pass, would, enough, information, vueserverrenderer, modules, box, registers, component, context, leverage, way, collect, call, above, yes, generated, map, mappings, their, chunks, output, directory, refer, demos, setup, move, creation, usage, behind, result, reading, root, since, correct, checking, process, node_env, indicates, specify, our, look, loaded, don, through, normal, changed, originalurl, __dirname, ssrfixstacktrace, caught, fix, stracktrace, maps, catch, text, content, 200, status, send, replace, inject, reactdomserver, calls, appropriate, required, invalidation, similar, usable, there, transformindexhtml, applies, global, preambles, apply, injects, utf, resolve, readfilesync, try, step, implementing, handler, vitedevserver, 3000, listen, tackle, ref, parent, take, disables, over, decouple, therefore, recommended, statically, allow, tree, shaking, unused, meta, prefer, long, precisely, include, where, markup, injected, exports, agnostic, universal, mounts, element, renders, typical, playground, setups, references, questions, usually, helpful, channel, help, meant, library, authors, goal, sure, higher, tools, first, said, applications, successfully, top, native, section, prior, experience, choice, focus, details, specifically, refers, front, preact, finally, hydrating, looking, traditional, still, encounter, bugs, unsupported, proceed, risk, sponsors, migration, comparisons, deploying, handling, features, getting, started, why, documentation, covers, latest, old,

Text of the page (random words):
server side rendering vite this documentation covers vite 2 old version for the latest version see https vite dev vite guide config plugins links twitter discord chat awesome vite dev community rollup plugins compat changelog languages english 简体中文 日本語 github guide config plugins links twitter discord chat awesome vite dev community rollup plugins compat changelog languages english 简体中文 日本語 github guide why vite getting started features using plugins dependency pre bundling static asset handling building for production deploying a static site env variables and modes server side rendering ssr example projects source structure conditional logic setting up the dev server building for production generating preload directives pre rendering ssg ssr externals ssr specific plugin logic ssr target ssr bundle backend integration comparisons migration from v1 apis plugin api hmr api javascript api config reference sponsors server side rendering experimental ssr support is still experimental and you may encounter bugs and unsupported use cases proceed at your own risk note ssr specifically refers to front end frameworks for example react preact vue and svelte that support running the same application in node js pre rendering it to html and finally hydrating it on the client if you are looking for integration with traditional server side frameworks check out the backend integration guide instead the following guide also assumes prior experience working with ssr in your framework of choice and will only focus on vite specific integration details low level api this is a low level api meant for library and framework authors if your goal is to create an application make sure to check out the higher level ssr plugins and tools at awesome vite ssr section first that said many applications are successfully built directly on top of vite s native low level api help if you have questions the community is usually helpful at vite discord s ssr channel example projects vite provides built in support for server side rendering ssr the vite playground contains example ssr setups for vue 3 and react which can be used as references for this guide vue 3 react source structure a typical ssr application will have the following source file structure index html server js main application server src main js exports env agnostic universal app code entry client js mounts the app to a dom element entry server js renders the app using the framework s ssr api the index html will need to reference entry client js and include a placeholder where the server rendered markup should be injected div id app ssr outlet div script type module src src entry client js script you can use any placeholder you prefer instead of ssr outlet as long as it can be precisely replaced conditional logic if you need to perform conditional logic based on ssr vs client you can use if import meta env ssr server only logic this is statically replaced during build so it will allow tree shaking of unused branches setting up the dev server when building an ssr app you likely want to have full control over your main server and decouple vite from the production environment it is therefore recommended to use vite in middleware mode here is an example with express server js const fs require fs const path require path const express require express const createserver createviteserver require vite async function createserver const app express create vite server in middleware mode this disables vite s own html serving logic and let the parent server take control in middleware mode if you want to use vite s own html serving logic use html as the middlewaremode ref https vitejs dev config server middlewaremode const vite await createviteserver server middlewaremode ssr use vite s connect instance as middleware app use vite middlewares app use async req res serve index html we will tackle this next app listen 3000 createserver here vite is an instance of vitedevserver vite middlewares is a connect instance which can be used as a middleware in any connect compatible node js framework the next step is implementing the handler to serve server rendered html app use async req res next const url req originalurl try 1 read index html let template fs readfilesync path resolve __dirname index html utf 8 2 apply vite html transforms this injects the vite hmr client and also applies html transforms from vite plugins e g global preambles from vitejs plugin react template await vite transformindexhtml url template 3 load the server entry vite ssrloadmodule automatically transforms your esm source code to be usable in node js there is no bundling required and provides efficient invalidation similar to hmr const render await vite ssrloadmodule src entry server js 4 render the app html this assumes entry server js s exported render function calls appropriate framework ssr apis e g reactdomserver rendertostring const apphtml await render url 5 inject the app rendered html into the template const html template replace ssr outlet apphtml 6 send the rendered html back res status 200 set content type text html end html catch e if an error is caught let vite fix the stracktrace so it maps back to your actual source code vite ssrfixstacktrace e next e the dev script in package json should also be changed to use the server script instead scripts dev vite dev node server building for production to ship an ssr project for production we need to produce a client build as normal produce an ssr build which can be directly loaded via require so that we don t have to go through vite s ssrloadmodule our scripts in package json will look like this scripts dev node server build client vite build outdir dist client build server vite build outdir dist server ssr src entry server js note the ssr flag which indicates this is an ssr build it should also specify the ssr entry then in server js we need to add some production specific logic by checking process env node_env instead of reading the root index html use the dist client index html as the template instead since it contains the correct asset links to the client build instead of await vite ssrloadmodule src entry server js use require dist server entry server js instead this file is the result of the ssr build move the creation and all usage of the vite dev server behind dev only conditional branches then add static file serving middlewares to serve files from dist client refer to the vue and react demos for working setup generating preload directives vite build supports the ssrmanifest flag which will generate ssr manifest json in build output directory build client vite build outdir dist client build client vite build outdir dist client ssrmanifest the above script will now generate dist client ssr manifest json for the client build yes the ssr manifest is generated from the client build because we want to map module ids to client files the manifest contains mappings of module ids to their associated chunks and asset files to leverage the manifest frameworks need to provide a way to collect the module ids of the components that were used during a server render call vitejs plugin vue supports this out of the box and automatically registers used component module ids on to the associated vue ssr context src entry server js const ctx const html await vueserverrenderer rendertostring app ctx ctx modules is now a set of module ids that were used during the render in the production branch of server js we need to read and pass the manifest to the render function exported by src entry server js this would provide us with enough information to render preload directives for files used by async routes see demo source for full example pre rendering ssg if the routes and the data needed for certain routes are known ahead of time we can pre render these routes into static html using the same logic as production ssr this can also be considered a form of static site generation ssg see demo pre render script for working example ssr externals many dependencies ship both esm and commonjs files when running ssr a dependency that provides commonjs builds can be externalized from vite s ssr transform module system to speed up both dev and build for example instead of pulling in the pre bundled esm version of react and then transforming it back to be node js compatible it is more efficient to simply require react instead it also greatly improves the speed of the ssr bundle build vite performs automated ssr externalization based on the following heuristics if a dependency s resolved esm entry point and its default node entry point are different its default node entry is probably a commonjs build that can be externalized for example vue will be automatically externalized because it ships both esm and commonjs builds otherwise vite will check whether the package s entry point contains valid esm syntax if not the package is likely commonjs and will be externalized as an example react dom will be automatically externalized because it only specifies a single entry which is in commonjs format if this heuristics leads to errors you can manually adjust ssr externals using ssr external and ssr noexternal config options in the future this heuristics will likely improve to detect if the project has type module enabled so that vite can also externalize dependencies that ship node compatible esm builds by importing them via dynamic import during ssr working with aliases if you have configured aliases that redirects one package to another you may want to alias the actual node_modules packages instead to make it work for ssr externalized dependencies both yarn and pnpm support aliasing via the npm prefix ssr specific plugin logic some frameworks such as vue or svelte compiles components into different formats based on client vs ssr to support conditional transforms vite passes an additional ssr property in the options object of the following plugin hooks resolveid load transform example export function myssrplugin return name my ssr transform code id options if options ssr perform ssr specific transform the options object in load and transform is optional rollup is not currently using this object but may extend these hooks with additional metadata in the future note before vite 2 7 this was informed to plugin hooks with a positional ssr param instead of using the options object all major frameworks and plugins are updated but you may find outdated posts using the previous api ssr target the default target for the ssr build is a node environment but you can also run the server in a web worker packages entry resolution is different for each platform you can configure the target to be web worker using the ssr target set to webworker ssr bundle in some cases like webworker runtimes you might want to bundle your ssr build into a single javascript file you can enable this behavior by setting ssr noexternal to true this will do two things treat all dependencies as noexternal throw an error if any node js built ins are imported suggest changes to this page env variables and modes backend integration