nuxt.config.ts Basics

Every Nuxt project has exactly one configuration entry point: nuxt.config.ts at the project root. It's a plain TypeScript file exporting a single object, and it's where anything that isn't a convention-based file (a page, a component, a composable) gets configured.

The shape of the file

// nuxt.config.ts
export default defineNuxtConfig({
  devtools: { enabled: true },

  css: ["~/assets/main.css"],

  modules: ["@nuxtjs/tailwindcss", "@pinia/nuxt"],

  app: {
    head: {
      title: "My Nuxt App",
      meta: [{ name: "description", content: "Built with Nuxt" }],
    },
  },
});

defineNuxtConfig is a helper that gives you type-checking and editor autocomplete on every option — it doesn't transform the object, it just types it. modules is worth calling out specifically: Nuxt's ecosystem is largely distributed as modules (Tailwind CSS, Pinia, image optimization, i18n, and many more) that you install with a package manager and then list here — each one hooks into the build process to add config, components, or composables automatically.

Route rules — per-route behavior from one file

routeRules lets you override rendering behavior for specific paths without touching the pages themselves — useful for the SSR/SSG/CSR mix discussed earlier:

export default defineNuxtConfig({
  routeRules: {
    "/": { prerender: true },                 // build once, serve as static HTML
    "/dashboard/**": { ssr: false },          // client-only, e.g. behind auth
    "/blog/**": { swr: 3600 },                // serve cached, revalidate hourly
    "/admin/**": { index: false },            // exclude from search engines
  },
});

This is powerful precisely because it's centralized: instead of hunting through individual page files to know how /admin/* is rendered, it's declared in one place alongside every other route's behavior.

Why one config file, not scattered settings

A plain Vite + Vue project typically spreads configuration across vite.config.js, a router file, an ESLint config, and whatever else each library needs. Nuxt centralizes framework-level configuration in nuxt.config.ts specifically because a module might need to touch several of those systems at once — installing @pinia/nuxt, for instance, needs to register a Vite plugin, add an auto-import, and add TypeScript types, all from one line in modules. The trade-off is that this file can grow large in a bigger project, but it stays the single place to look, rather than one of several.

The next lessons cover two things that live here too: environment-specific values via runtimeConfig, and app-wide setup code via plugins.