"Our Nuxt app has 400 components in one folder" is a real prompt, and the answer is not a folder rename. Structure is about boundaries: what may depend on what, who owns each part, and how the tooling enforces it. Nuxt's conventions help and constrain; layers and monorepos extend them; micro-frontends are the option to reach for last.

Know

• By type versus by feature. Nuxt's default is by type (components/, composables/, pages/, server/api/), which works to a few dozen components and then hides which files belong together. Feature folders (app/features/checkout/{components,composables,stores,utils}) group by domain. Nuxt scans components/ recursively and only the top level of composables/, and pages must stay in pages/, so feature folders are wired with components.dirs (with a prefix), imports.dirs for composables and utils, and pages:extend or layers when pages should live with features.
• Dependency direction: features may depend on shared kernels (shared/, a UI layer, app/lib), never on each other's internals; cross-feature communication goes through a feature's public index.ts, events, or the store. On the server, handlers depend on services, services on repositories and shared schemas, nothing depends on handlers.
• Enforcing boundaries with tooling, not code review alone: eslint-plugin-import-x's no-restricted-paths, eslint-plugin-boundaries, or dependency-cruiser with rules ("features may not import other features' internals", "shared may not import Vue or Nitro"), plus TypeScript project references (Nuxt already splits app, server and shared) and CODEOWNERS per feature.
• The shared kernel is small and stable: schemas, DTO types, formatting utilities, error types, constants. Growth of shared/ into a dumping ground is the usual decay; review it as an API.
• Nuxt layers as the unit of reuse: a UI layer (tokens, primitives, config preset), domain layers (auth pages plus server routes plus composables), and app layers that assemble them; layers ship pages and server routes together, which packages cannot, and consumers override by file path. The layers section has the mechanics; architecturally, layers are how one team shares conventions across several Nuxt apps without a platform team.
• Monorepos: pnpm workspaces (apps/*, packages/*, layers/*), workspace:* dependencies, a shared tsconfig and ESLint config package, Turborepo or Nx for task graphs and remote caching (build depends on ^build), Changesets for versioning published packages, pnpm --filter for targeted runs. Internal packages are consumed from source in dev (exports pointing at src in dev conditions) or built; keep one Vue and one Nuxt version across the workspace to avoid duplicate instances.
• Micro-frontends: independently deployed fragments composed at runtime (Module Federation via the Vite plugin, iframes, web components, or edge composition). Justified when several teams must deploy on independent cadences and the organisational cost of coordination exceeds the technical cost; the costs are duplicated dependencies and design drift, cross-fragment routing and auth, shared state, performance (multiple Vue runtimes), and testing. For most Nuxt organisations, layers plus a monorepo plus route-level ownership deliver team autonomy without runtime composition; Nuxt's future.multiApp prepares for multiple apps on one page but is not a micro-frontend framework.
• Naming and colocation: feature-prefixed component names (CheckoutSummary), tests next to code or mirrored under test/, one component per file, index files as public APIs, README.md per feature with its boundaries.
• Evolution path: extract a feature folder from the type-based tree; when two apps need it, move it into a layer; when non-Nuxt consumers need it, a package; when teams need independent deploys, separate apps sharing layers. Each step is reversible until runtime composition.

How it works

Feature folders in a Nuxt 4 app, wired through configuration:

app/
├── features/
│   ├── checkout/
│   │   ├── components/   CheckoutSummary.vue, CheckoutAddressForm.vue
│   │   ├── composables/  useCheckout.ts
│   │   ├── stores/       checkout.ts
│   │   ├── index.ts      public API: export { useCheckout } from './composables/useCheckout'
│   │   └── README.md     boundaries, owners
│   └── catalog/ ...
├── pages/                 thin: import feature components, no logic
├── layouts/
└── lib/                   app-wide non-domain helpers
shared/                    schemas, DTOs, constants (no Vue, no Nitro)
server/
├── api/                   handlers (thin)
├── services/              domain logic, takes db as a parameter
└── utils/                 auto-imported helpers (useDb, requireRole)

export default defineNuxtConfig({
  components: [
    { path: '~/features/checkout/components', prefix: 'Checkout' },
    { path: '~/features/catalog/components', prefix: 'Catalog' },
    '~/components',
  ],
  imports: { dirs: ['features/*/composables', 'features/*/stores', 'lib'] },
  hooks: {
    'pages:extend'(pages) {
      // feature-owned pages can be registered here when they should live with the feature
      pages.push({ name: 'checkout', path: '/checkout', file: '~/features/checkout/pages/index.vue' })
    },
  },
})

Boundaries enforced by lint, so they survive the next hire:

import withNuxt from './.nuxt/eslint.config.mjs'
import boundaries from 'eslint-plugin-boundaries'

export default withNuxt({
  plugins: { boundaries },
  settings: {
    'boundaries/elements': [
      { type: 'feature', pattern: 'app/features/*', capture: ['name'] },
      { type: 'shared', pattern: 'shared/*' },
      { type: 'lib', pattern: 'app/lib/*' },
      { type: 'pages', pattern: 'app/pages/*' },
      { type: 'server', pattern: 'server/*' },
    ],
  },
  rules: {
    'boundaries/element-types': ['error', {
      default: 'disallow',
      rules: [
        { from: 'feature', allow: ['shared', 'lib', ['feature', { name: '${from.name}' }]] }, // a feature may import itself, shared and lib
        { from: 'pages', allow: ['feature', 'shared', 'lib'] },
        { from: 'server', allow: ['shared', 'server'] },
        { from: 'shared', allow: ['shared'] },
      ],
    }],
  },
})

A monorepo that shares layers and packages across two Nuxt apps:

packages:
  - apps/*
  - layers/*
  - packages/*
catalog:
  nuxt: ^4.5.2
  vue: ^3.5.43

{
  "dependencies": {
    "nuxt": "catalog:",
    "@team/layer-ui": "workspace:*",
    "@team/layer-auth": "workspace:*",
    "@team/schemas": "workspace:*"
  }
}

export default defineNuxtConfig({ extends: ['@team/layer-ui', '@team/layer-auth'] })

{
  "tasks": {
    "build": { "dependsOn": ["^build"], "outputs": [".output/**", "dist/**"] },
    "typecheck": { "dependsOn": ["^build"] },
    "test": { "dependsOn": ["^build"] }
  }
}

Exercise

Be able to say