create-vite-plugin

# Vite plugin implementation Inspect the installed Vite and Rolldown versions, application config, neighboring plugins, and serve/build tests before implementing. Vite 8's `Plugin` extends Rolldown's `Plugin`; keep generic resolution, loading, transforms, graph work, and output in a Rolldown plugin and add a Vite layer only for Vite-specific behavior. ## Workflow 1. Classify the requirement. Use a Rolldown plugin directly for host-generic module/build behavior. Use a Vite plugin for `config`, environments, `configureServer`, HTML, HMR, preview, or behavior that intentionally differs between serve and build. 2. Decide activation explicitly. Use `apply: 'serve'` or `apply: 'build'` when only one command is valid. A generic build-only Rolldown plugin may instead live in `build.rolldownOptions.plugins`; do not initialize asset generation or destructive output logic during dev. 3. Enable `build.rolldownOptions.experimental.nativeMagicString: true` in repository-owned Vite builds and set `build.sourcemap: true` when production maps should be emitted. This affects Vite's production Rolldown build but does not add Rolldown AST or MagicString metadata to Vite transform hooks; use the VJSC Vite adapter for transforms that need it. 4. Use `enforce` only for a real Vite tier requirement. Prefer per-hook `order` for a specific Rolldown hook. Prove ordering with behavior tests rather than depending on array position. 5. Use `config` to return a partial Vite config that may be deeply merged. Do not attempt to inject plugins from that hook. Read final values in `configResolved`; keep environment-specific state out of global app hooks. 6. Treat resolve/load/transform hooks as per-environment. Use Vite's environment APIs or separate plugin instances when builds may run concurrently. Worker plugins must be created by `worker.plugins` and receive fresh instances. 7. Normalize paths before Vite-specific ID comparisons. For cross-host VJSC code, reuse package `src/utils` module-ID and path helpers instead of importing Vite utilities into the generic plugin. 8. Remember that aliases affect module resolution, not authored import text retained in generated source or JSON. Resolve dependencies through the host, then perform only the packaging rewrite required by the output format. 9. Test serve and build separately. Cover activation, resolved config, virtual modules, transform order, SSR/environment flags when relevant, HMR invalidation, HTML output, existing application entries, and emitted assets. Read [references/api-and-host-contracts.md](references/api-and-host-contracts.md) when choosing between a raw Rolldown plugin, `build.rolldownOptions.plugins`, a top-level Vite plugin, or an environment-aware plugin. Use `packages/vjsc/src/vite/index.ts` as the thin-adapter example, `packages/vjsc/src/plugins/tests` for direct Rolldown coverage, and `packages/skins/build/tests/vite.test.ts` as the Vite host test anchor. ## Validation Run focused programmatic Vite serve/build tests, the underlying Rolldown tests when shared, the owning package build, `pnpm typecheck`, and `pnpm check:workspace`. Avoid E2E coverage unless the requested behavior genuinely crosses the browser boundary. ## Example Input: “Make this source transform available in Vite and rebuild when its config changes.” Output: A host-generic Rolldown transform reused by a thin Vite entry, Vite-only watch/config handling where needed, explicit serve/build activation, and tests proving identical transformed source through direct Rolldown and Vite.