The CWA Layer
The @cwa/nuxt module ships as a Nuxt layer. A layer is a self-contained Nuxt application whose pages, layouts, components, and plugins are merged into your project automatically. You add the layer with extends: ['@cwa/nuxt/layer'] in nuxt.config.ts (see Module Setup for why the package name beats a node_modules path), and the layer registers the module for you — not the other way round. Registering the module directly under modules leaves out the layer's auth pages, admin panel, root layout and middleware.
What the Layer Provides
Pages (auto-registered)
CWA registers several pages automatically. These work out-of-the-box and require no configuration:
Auth pages (public): /login, /forgot-password, /reset-password/[username]/[token], /verify-email/[username]/[token] and /confirm-new-email/[username]/[newEmail]/[token]. See Auth Pages for the component and composable behind each.
Content pages (dynamic, SSR):
| Route | Purpose |
|---|---|
/ and /* | Catch-all CWA content route — resolves routes from the API manifest and renders your layout + page template |
Admin panel (client-only, admin users only): the pages under /_cwa, for layouts, pages, page data, routes, users, site settings and orphaned resources. Admin Panel › Admin Routes lists every route.
Layout
cwa-root-layout is registered by the layer. It is the Nuxt layout used on all CWA content pages. It mounts the admin header and resource manager panel when auth.isAdmin is true, then renders the <slot /> — which is where your CWA-resolved layout component appears.
cwa-root-layout is applied automatically to every page that doesn't set its own layout (change the name it registers under with the cwa.layoutName option).
A page of your own that isn't CWA-managed content must set cwa: { disabled: true } in definePageMeta, or the global CWA route middleware asks the API for a Route at its path. See definePageMeta CWA Options.
Route Middleware
Besides the global route resolver, the layer ships two named middleware for guarding your own pages: cwa-auth (a signed-in user) and cwa-admin (a user with ROLE_ADMIN). They only run on pages that ask for them, and the layer's own /_cwa admin pages use cwa-admin. See Protecting Pages.
Reusable UI Components
The layer registers a set of <CwaUi...> components that the admin panel uses internally. These are also available in your own templates:
| Component | Description |
|---|---|
<CwaUiFormInput> | Styled text input. Takes v-model, or the return of useCwaResourceModel as :model, which also outlines it while another admin has it in focus and shows a co-editing conflict beside it |
<CwaUiFormLabelWrapper> | Label + control layout — wrap CwaUiFormInput and the selects in it, which take no label prop. <CwaUiFormToggle> takes its own required label |
<CwaUiFormSelect> | Styled select with popover option list. Takes v-model only |
<CwaUiSelect> | Styled select that can allow several choices (multiple). Takes v-model or :model, like <CwaUiFormInput> |
<CwaUiFormToggle> | Boolean toggle switch. Takes v-model or :model, like <CwaUiFormInput> |
<CwaUiFieldPresence> | Wraps a field of your own and outlines it with the name of another admin who has it in focus. Takes :model; bind the model's focusListeners on it. See useCwaResourceModel › Your Own Field Editor |
<CwaUiRemoteChangeConflict> | The Name changed this · Use theirs / Keep mine line. Takes a model's remoteChange as :change |
<CwaUiFormFile> | File upload control (used in upload admin tabs) |
<CwaUiFormButton> | Styled button |
<CwaUiAlertInfo> | Info notice block |
<CwaUiAlertWarning> | Warning notice block |
<CwaUiProgressBar> | Animated progress bar. For the page loading bar, use <CwaLoadingIndicator> in app.vue instead |
<CwaUiHamburger> | Mobile hamburger icon |
<CwaUiDatePicker> | Date and time field with a calendar popover, in UTC ISO strings. See Date and Time Pickers |
<CwaUiCalendar> | Calendar for a date, a range or several dates |
<CwaUiInputDate> | Segmented date and time field without the calendar |
These components are styled with CWA's bundled CSS (cwa.css). They are primarily intended for admin and auth pages, but you can use them anywhere.
Overriding Layer Pages
Any page the layer provides can be overridden by creating the same path in your project's app/app/pages/ directory. Nuxt's layer merging means your file wins:
app/app/pages/login.vue ← your override, takes precedence
← layer's /login is ignored
See Customising the Login Page for an example.