Create a SvelteKit app, learn the folders it gives you, and run the dev, build, and preview commands.
Why: the sv CLI scaffolds a complete SvelteKit 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 dlx sv create my-appPick "SvelteKit minimal", then TypeScript 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: SvelteKit uses file-system routing — the shape of your folders under src/routes IS your URL structure, so knowing what each folder is for tells you where code goes. Note: "routing" means matching a URL to the code that renders it.
my-app/ ├─ src/ │ ├─ routes/ # every route lives here — folders are URL segments │ │ ├─ +layout.svelte # shared shell wrapped around pages │ │ └─ +page.svelte # the UI for "/" (the home page) │ ├─ lib/ # shared code; import it with the $lib alias │ ├─ app.html # the HTML document shell │ └─ hooks.server.ts # runs on every server request (optional) ├─ static/ # files served as-is, e.g. /favicon.png ├─ svelte.config.js # SvelteKit configuration (adapter, etc.) └─ vite.config.ts # build tooling configuration
Why: a page is a file named +page.svelte. One .svelte file holds its logic in <script> and its markup right below — no separate template. The folder it sits in decides its URL.
<!-- src/routes/+page.svelte -> served at "/" -->
<script lang="ts">
let name = 'SvelteKit'
</script>
<h1>Hello {name}!</h1>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