Entrypoints

Understand what belongs on the package root and what each framework-specific entrypoint owns.

Every ViteHub feature keeps the public runtime API on the package root and moves framework wiring into dedicated integration entrypoints. Your application code stays the same across Vite, Nitro, and Nuxt because runtime helpers never move between entrypoints.

The four surfaces

SurfaceOwnsUse it when
@vitehub/<feature>Public runtime helpers, define* APIs, and typesYou are writing application code, handlers, tasks, or shared utilities.
@vitehub/<feature>/viteCanonical build-time plugin and planningYou integrate directly with Vite.
@vitehub/<feature>/nitroNitro wiring, emitted routes, storage bindings, tasks, and runtime pluginsYou use Nitro directly.
@vitehub/<feature>/nuxtThin Nuxt wrapper over Nitro integrationYou use Nuxt and want ViteHub to register through Nuxt modules.

What belongs on the package root

The package root stays stable across frameworks. That is where runtime helpers such as runQueue(), runWorkflow(), getKV(), getBlob(), runBrowser(), and feature-specific define*() APIs live.

server/api/example.ts
import { defineQueue, runQueue } from '@vitehub/queue'

Use package-root imports in reusable server helpers, route handlers, and tests. Do not import those runtime APIs from /vite, /nitro, or /nuxt.

What /vite owns

/vite is the canonical build-time adapter. It reads top-level feature config, discovers definitions, plans runtime artifacts, and exposes the bridge Nitro reuses later.

vite.config.ts
import { defineConfig } from 'vite'
import { hubQueue } from '@vitehub/queue/vite'

export default defineConfig({
  plugins: [hubQueue()],
})

Use this surface when Vite is the integration point you control directly.

What /nitro owns

/nitro reuses the same bridge outputs as /vite, then adds server-specific behavior such as routes, storage bindings, tasks, and provider inference.

nitro.config.ts
import { defineNitroConfig } from 'nitro/config'

export default defineNitroConfig({
  modules: ['@vitehub/queue/nitro'],
})

Use this surface for standalone Nitro apps.

What /nuxt owns

/nuxt stays thin. It installs the Nitro module and forwards feature config into Nitro instead of creating an independent integration layer.

nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@vitehub/queue/nuxt'],
})

Use this surface for Nuxt apps, especially when you want module registration to stay consistent with the rest of your Nuxt setup.

The registration line changes across frameworks. The underlying feature bridge does not. Read Architecture for the full layer model.