Nuxt layers

Every official package is a Nuxt layer whose package entry point is nuxt.config.ts. Each config supplies a stable $meta.name; code inside a layer may use that named Nuxt alias, while cross-package code uses documented package exports.

Official composition

@nuxt-customer-portal/preset includes core, ui, authentication, organizations, and administration. Add @nuxt-customer-portal/service-requests and @nuxt-customer-portal/timesheets independently.

import { definePortalConfig } from '@nuxt-customer-portal/kit'

export default definePortalConfig({
  layers: [
    '@nuxt-customer-portal/preset',
    '@nuxt-customer-portal/timesheets'
  ]
})

import portal from './portal.config'

export default defineNuxtConfig({ extends: portal.nuxtLayers })

Public imports

Stable integration paths include:

• @nuxt-customer-portal/core/feature for feature and surface contracts;
• @nuxt-customer-portal/core/server for tenant-aware server adapters;
• @nuxt-customer-portal/core/schema for official core schema exports;
• each business package's feature, types, schema, and portal-manifest exports.

The former #portal, #types, filesystem #layers/*, and subtree paths are intentionally unsupported. Packages resolve their own CSS and assets relative to import.meta.url.

Local layers

Use localPortalLayer() for deployment-owned features. A local layer has the same manifest semantics as official providers, including dependencies and immutable migrations:

localPortalLayer({
  id: 'acme-billing',
  source: './layers/acme-billing',
  schema: './layers/acme-billing/server/db/schema',
  migrations: './layers/acme-billing/migrations',
  dependsOn: ['core']
})

Removing a layer from configuration disables code only. It never removes stored data.