Create a Nuxt app, learn the folders it gives you, and run the dev, build, and preview commands.
Why: this command scaffolds a complete Nuxt app — config, folders, and a working page — so you never start from an empty directory. Note: "scaffold" just means it generates the starter files for you.
$ pnpm create nuxt my-appAccept the defaults when the CLI asks. This creates a folder called my-app with a ready-to-run project inside.
Why: these are the commands you use every day. "dev" runs a local server that reloads as you edit; "build" compiles an optimized version for production; "preview" runs that built version locally so you can check it.
$ cd my-app$ pnpm dev$ pnpm build$ pnpm previewWhy: Nuxt gives every folder a job, so knowing what each is for tells you where code goes — and most of them are "auto-imported" (usable without an import line). Note: app code lives under app/; server code lives under server/.
my-app/ ├─ app/ │ ├─ app.vue # the root component │ ├─ pages/ # file-based routes — files/folders are URL segments │ ├─ components/ # auto-imported components │ ├─ composables/ # auto-imported composables (useXxx) │ ├─ layouts/ # shared shells │ └─ middleware/ # route guards ├─ server/ # API routes & server code (server/api/…) ├─ public/ # files served as-is, e.g. /favicon.ico └─ nuxt.config.ts # Nuxt configuration
Why: once a pages/ folder exists, each .vue file in it becomes a route. A Vue component is one .vue file: logic in <script setup>, markup in <template>. The file’s path decides its URL — index.vue is "/".
<!-- app/pages/index.vue -> served at "/" -->
<script setup lang="ts">
const name = 'Nuxt'
</script>
<template>
<h1>Hello {{ name }}!</h1>
</template>Why: real apps pull in libraries. Use your package manager to add (or remove) them; the -D flag marks a package as a dev-only tool (like a linter) that is not shipped to users.
$ pnpm add zod$ pnpm add -D vitest$ pnpm remove zod