Manifest: Struct<
{
assets: Array$<typeof String$>;
author: optional<typeof String$>;
dependencies: optional<Record$<typeof String$, typeof String$>>;
dependsOn: optional<Array$<typeof String$>>;
description: optional<typeof String$>;
devEntry: optional<typeof String$>;
homePage: optional<typeof String$>;
icon: optional<
Struct<{ hue: optional<typeof String$>; key: filter<typeof String$> }>,
>;
key: filter<typeof String$>;
name: filter<typeof String$>;
screenshots: optional<
Array$<
Struct<
{ dark: optional<typeof String$>; light: optional<typeof String$> },
>,
>,
>;
source: optional<typeof String$>;
spec: optional<typeof String$>;
tags: optional<Array$<typeof String$>>;
version: filter<typeof String$>;
},
> = ...
Schema for a third-party plugin manifest.
Production manifests are published as a sibling of the plugin's entry module (PLUGIN_ENTRY_FILENAME) and advertise every file the plugin needs at runtime so the host can eagerly cache them for offline use.
Dev manifests (served by
vite devvia composerPlugin) setdevEntryto point at the unbundled source entry. The host's loader treats the presence ofdevEntryas the dev-mode signal: it imports the entry directly from the dev server, skips eager asset caching, and skips static stylesheet injection (Vite handles CSS via runtime<style>injection during HMR).assetsis not required to enumerate every file in dev mode — chunks and styles flow through the dev server on demand.