Configuration Steps
Configure Vite entry and manifest
In your Vite config, configure the entry and enable build manifest:
vite.config.js
If you haven’t disabled the module preload polyfill, you also need to import the polyfill in your entry:
Set up development scripts
For development, inject the following in your server’s HTML template (substitute In order to properly serve assets, you have two options:
http://localhost:5173 with the local URL Vite is running at):- Make sure the server is configured to proxy static assets requests to the Vite server
- Set
server.originso that generated asset URLs will be resolved using the back-end server URL instead of a relative path
Generate manifest for production
For production, after running
vite build, a .vite/manifest.json file will be generated alongside other asset files. An example manifest file looks like this:.vite/manifest.json
Manifest Structure
The manifest has aRecord<name, chunk> structure where each chunk follows the ManifestChunk interface:
Manifest Entry Types
Each entry in the manifest represents one of the following:Entry chunks
Entry chunks
Generated from files specified in
build.rollupOptions.input. These chunks have isEntry: true and their key is the relative src path from project root.Dynamic entry chunks
Dynamic entry chunks
Generated from dynamic imports. These chunks have
isDynamicEntry: true and their key is the relative src path from project root.Non-entry chunks
Non-entry chunks
Their key is the base name of the generated file prefixed with
_.Asset chunks
Asset chunks
Generated from imported assets like images, fonts. Their key is the relative src path from project root.
CSS files
CSS files
When
build.cssCodeSplit is false, a single CSS file is generated with the key style.css. When build.cssCodeSplit is not false, the key is generated similar to JS chunks (i.e. entry chunks will not have _ prefix and non-entry chunks will have _ prefix).Rendering Tags in Production
Specifically, a backend generating HTML should include the following tags given a manifest file and an entry point. Note that following this order is recommended for optimal performance:- A
<link rel="stylesheet">tag for each file in the entry point chunk’scsslist (if it exists) - Recursively follow all chunks in the entry point’s
importslist and include a<link rel="stylesheet">tag for each CSS file of each imported chunk’scsslist (if it exists) - A tag for the
filekey of the entry point chunk. This can be<script type="module">for JavaScript,<link rel="stylesheet">for CSS - Optionally,
<link rel="modulepreload">tag for thefileof each imported JavaScript chunk, again recursively following the imports starting from the entry point chunk
Example: Entry Point views/foo.js
Following the example manifest above, for the entry point views/foo.js the following tags should be included in production:
Example: Entry Point views/bar.js
For the entry point views/bar.js:
Pseudo implementation of importedChunks
Pseudo implementation of importedChunks
An example pseudo implementation of
importedChunks in TypeScript (This will need to be adapted for your programming language and templating language):