The Concepts chapters explain the ideas the rest of the docs assume. They are short, and they contain the sentences interviewers paraphrase into questions: "what runs on the server and in what order", "what is a server component", "why does Nuxt split the TypeScript config".

Know — Auto-imports

• Built-in: Vue APIs (ref, computed, …) and Nuxt composables/utils are auto-imported. Directory-based: composables/, utils/, and shared/utils + shared/types. Explicit imports from #imports. Disabling: imports.autoImport: false (keeps #imports); partially with imports.scan: false (keeps built-ins, stops directory scanning). Components are auto-imported by name. Third-party packages via imports.presets ({ from: 'vue-i18n', imports: ['useI18n'] }).

Know — Nuxt Lifecycle

• Server (per request): server plugins (once, at startup) → server middleware → app plugins → route validation → app middleware → page and components (setup, data fetching) → HTML output.
• Client: app plugins → route validation → app middleware → mount and hydrate → Vue lifecycle (onMounted, …). Later navigations repeat validation, middleware and page setup on the client.

Know — Vue.js Development

• Nuxt is Vue with SFCs, auto-imports and Vue Router; Vapor Mode is supported experimentally in interop mode: vue: { vapor: true } installs the interop plugin, the app root stays virtual DOM and you mark components with <script setup vapor>; it requires a Vue 3.6 release candidate, and the docs list limitations (no full-Vapor app, no $el on Vapor template refs, no Options API, some built-ins cannot inspect Vapor slot children, keyed onPrehydrate falls back, composables after await may lose context). Versus Nuxt 2: faster rendering, smaller bundle, Composition API, TypeScript.

Know — Rendering Modes

• Universal rendering (default): server-rendered HTML then hydration; client-side rendering (ssr: false); hybrid rendering with routeRules (ssr, prerender, swr, isr, cache, headers, redirect, cors); edge-side rendering when deployed to edge runtimes (Cloudflare, Vercel Edge, Netlify Edge).

Know — Server Components

• A server component renders on the server, its HTML is embedded in the page, and no JavaScript for it ships to the client. Enabled by experimental.componentIslands (auto-enabled when a .server.vue component exists); set it explicitly for selectiveClient: true | 'deep' (allows nuxt-client on children) and remoteIsland. .server.vue makes a standalone server component; a paired Name.server.vue + Name.client.vue renders the server version first and swaps in the client one after hydration; <NuxtIsland> renders by name. Props are serialised, changing them refetches; still experimental with a roadmap issue.

Know — Server Engine

• Nitro: the API layer (server/api, server/routes, h3 handlers), direct API calls with $fetch on the server (no HTTP), typed API routes (return types inferred for $fetch), a standalone server in .output/server that needs no node_modules, universal deployment presets, storage (unstorage) and cache layers, hot reloading in development.

Know — Modules

• The modules directory at nuxt.com/modules; add with npx nuxt module add <name> (installs and registers); disable a module (4.3) by setting its config key to false (image: false); create with the module starter (see Module authoring).

Know — ES Modules

• Nuxt is ESM-first: background on CommonJS vs ESM, what counts as native ESM in Node ("type": "module", .mjs), valid imports (no directory or extension-less imports in ESM), and the problems that follow (packages shipping CJS with ESM syntax, default export interop). Troubleshooting: add the library to build.transpile, alias to a working entry, or fix default imports (import pkg from 'lib'; const { thing } = pkg). Library author guide: ship ESM with correct exports, .mjs/.cjs conditions, no require in ESM.

Know — TypeScript

• Type-checking is not run during build by default; use nuxt typecheck or typescript.typeCheck: true (needs vue-tsc and typescript). Auto-generated types in .nuxt/ (nuxt.d.ts, imports.d.ts, components.d.ts). Project references: Nuxt 4 generates tsconfig.app.json, tsconfig.server.json, tsconfig.shared.json and tsconfig.node.json so each context sees only its own globals; augment types per context (a declare module in the right tree). Strict checks are on (typescript.strict: true) with noUncheckedIndexedAccess available under typescript.tsConfig.

Know — Code Style

• ESLint through @nuxt/eslint (npx nuxt module add eslint), which generates a project-aware flat config eslint.config.mjs exporting withNuxt(...), with optional stylistic rules replacing Prettier.

How it works

export default defineNuxtConfig({
  modules: ['@nuxt/eslint', '@nuxt/image'],
  image: false, // 4.3: disable a module without removing it (e.g. in a layer consumer)
  imports: {
    presets: [{ from: 'vue-i18n', imports: ['useI18n'] }],
  },
  experimental: { componentIslands: { selectiveClient: true } },
  typescript: { typeCheck: true, tsConfig: { compilerOptions: { noUncheckedIndexedAccess: true } } },
  vue: { vapor: false }, // experimental interop mode; needs vue@^3.6.0-rc
})

<script setup lang="ts">
// Renders on the server only; its script never reaches the browser.
const props = defineProps<{ html: string }>()
const rendered = await renderMarkdown(props.html) // heavy work stays on the server
</script>

<template>
  <div v-html="rendered" />
  <!-- with selectiveClient, an interactive child can opt back in -->
  <AddToCart nuxt-client />
</template>

import withNuxt from './.nuxt/eslint.config.mjs'

export default withNuxt({
  rules: { 'vue/multi-word-component-names': 'off' },
})

Exercise

Be able to say