Architecture
How ViteHub keeps one shared feature bridge across Vite, Nitro, and Nuxt.
Each ViteHub feature shares one bridge across Vite, Nitro, and Nuxt. Vite owns the canonical build-time planning, Nitro reuses that bridge and adds server behavior, and Nuxt installs the Nitro layer instead of rebuilding feature setup from scratch.
The stack
┌─────────────────────────────┐
│ Nuxt │ Full-stack framework
│ (extends Nitro + adds UI) │ @vitehub/*/nuxt
├─────────────────────────────┤
│ Nitro │ Server framework
│ (extends Vite + adds │ @vitehub/*/nitro
│ server runtime, routes, │
│ tasks, storage) │
├─────────────────────────────┤
│ Vite │ Build tool
│ (plugins, config, dev │ @vitehub/*/vite
│ server) │
└─────────────────────────────┘
Shared entrypoint model
Each feature ships the same four import surfaces:
| Surface | Responsibility |
|---|---|
@vitehub/* | Public runtime helpers, define* APIs, and types. |
@vitehub/*/vite | Canonical Vite adapter that reads top-level config and plans feature artifacts. |
@vitehub/*/nitro | Nitro integration layer that consumes the same bridge outputs and adds server-only wiring. |
@vitehub/*/nuxt | Thin Nuxt wrapper that installs the Nitro integration and forwards feature config. |
Read Entrypoints when you want the short version of that split.
Build-time and runtime responsibilities
The Vite plugin owns canonical build-time work:
- Reads top-level feature config from
vite.config.ts - Discovers definition files and plans them into runtime artifacts
- Generates type declarations
- Exposes the bridge that Nitro reuses through Nitro v3's Vite integration contract
Discovery paths still follow the framework surface you use:
- Nitro and Nuxt feature definitions live under
server/**such asserver/queues/**orserver/workflows/**
Nitro consumes the shared bridge outputs and adds server-side behavior:
- Registers aliases, handlers, plugins, tasks, and runtime config
- Wires storage bindings and provider-specific server hooks
- Adds routes when a feature needs them, such as queue consumers or workflow callbacks
- Infers the hosting provider from the Nitro preset when a feature supports hosted defaults
Nuxt stays intentionally thin:
- Registers the Nitro module automatically
- Forwards feature config into
nuxt.options.nitro - Adds Nuxt-specific hooks only when a feature genuinely needs them
- Keeps runtime APIs on the package root instead of creating a Nuxt-only runtime surface
Stable code across frameworks
Application code stays stable. The code that calls runQueue(), getKV(), or runBrowser() does not need to move when you switch from Nitro to Nuxt or when provider selection changes.
If you are trying to understand imports first, open Entrypoints. If you are trying to choose a primitive first, open Choose a package.