learn.nuxt.com: a Nuxt tutorial that runs in the browser through WebContainers

A tutorial whose code panel is a real filesystem

learn.nuxt.com is described as an interactive tutorial and playground for learning Nuxt, powered by Nuxt and WebContainers, and it is live at learn.nuxt.com. The project is explicitly labelled work in progress, with a warning that the architecture of the project is ready while the tutorial content is still work in progress and contributions are appreciated.

The interesting design decision is that the playground is not a simulation. A WebContainer is a browser-side Node.js environment, so the tutorial ships actual files into a running container, and the editor, the terminal and the dev server are all operating on that container's filesystem. The dependency list backs this up: @webcontainer/api is there, alongside @xterm/xterm and @xterm/addon-fit for the terminal panel, monaco-editor and @volar/monaco for the editor, and the language service packages @vue/language-service and @volar/monaco that connect Volar to the container filesystem.

The clearest evidence of what that buys you is in the completed roadmap items. There is a button to download the project as a zip, a button to restart the server, a terminal panel that opens and closes, an interactive shell, a file tree, and a display of the Nuxt and Vue versions from inside the container. The playground is not showing you a fake console output; it is reporting versions from a container that is actually running.

The project is heavily inspired by learn.svelte.dev, and the development history is unusual: Anthony Fu is building it from scratch on live streaming, with recordings of the full process on YouTube. That means the codebase doubles as a teaching artefact, which changes how you read it.

Guides are directories, and the .template folder is the payload

The content structure is where the coupling between tutorial text and running code lives.

Tutorial content sits in the content/en/ directory. Each route contains a number prefix, for example 1., to indicate the order, and that prefix is removed in the final URL. Each route uses a folder with an index.md, and that same folder can hold the extra files the guide needs. The number prefix system means you can reorder a chapter by renaming its directory, and the published URL stays clean.

The payload is a .template folder placed alongside the index.md. Inside it there are three conventional pieces. The .template/index.ts file holds the metadata for that guide, things like enabling or disabling features and file filters. The .template/files/ directory holds the files that get copied into the playground when the user opens that guide, merged with the basic template under template/basic/. The .template/solutions/ directory holds optional solutions for the tasks in that guide, merged with the guide files.

The merge behaviour is the part that makes a guide feel continuous rather than a series of isolated snapshots. The basic template is the constant base, the guide files layer on top, and the solutions layer on top of that. Combined with the roadmap item about only making necessary changes when navigating between guides, the intent is that moving from one guide to the next does not reset your container.

The equivalent structure for a Japanese translation lives under content/ja, done in collaboration with the Vue.js community. The project states plainly that it is not accepting new languages at the moment and points translators to a file for the details.

The toolchain in package.json explains most of the architecture

The manifest is where the design decisions are legible.

The project is named learn.nuxt.com, is private, is an ES module, and pins pnpm 10.15.1 as its package manager. The scripts are the standard Nuxt set, with build, dev, generate and preview mapped to the corresponding nuxt subcommands, plus typecheck, lint and format. The format script runs eslint with the fix flag rather than prettier, and the dev dependencies include @antfu/eslint-config along with @nuxt/eslint and the vue i18n plugin.

The dependency versions are not pinned to concrete numbers in the manifest. Almost every entry reads catalog:frontend or catalog:dev, which is the pnpm workspace catalog mechanism, and the repository contains a pnpm-workspace.yaml. The effect is that a single catalog entry governs a version across every package in the workspace, and renovate.json is present to keep those entries current. There is a patches/ directory as well, which is where pnpm patches live, and a splitpanes.d.ts typing file at the root for the splitpanes dependency used for the resizable layout.

The rest of the tree follows a Nuxt application shape: app.vue, pages/, components/, composables/, stores/, modules/, middleware/, plugins by way of the modules directory, server/ for the server routes, public/, styles/, templates/, i18n/, monaco/ for editor integration, structures/ and types/ for the content and data shapes, and content.config.ts plus @nuxt/content for the content layer. UnoCSS is present through uno.config.ts, and the theme is theme-vitesse.

One dependency deserves a note: birpc, the bidirectional RPC library, which is the natural way to talk between the browser, the WebContainer API and the server side of the app without hand-writing message channels.

What the roadmap says is finished, and what it says is not

The README carries a todolist, and reading the checkboxes tells you the shape of the project better than any description.

Completed items include the search feature, with a search in the command palette and a search button, and a Command K system. Navigation is done, with a dropdown for guide outlines, breadcrumbs, and previous and next buttons. SEO is done, with an OG image, meta tags and a sitemap. The playground itself has a release time display, shows the Nuxt and Vue versions from the container, uses a custom bundler for templates that replaces import.meta.glob by creating static virtual modules, has Monaco and Volar with Volar connected to the WebContainer filesystem, and offers a file tree. A basic editor, an interactive shell, restart server buttons, an open and close terminal panel, extracted playground injected utilities, a download as zip button, a refactor of logic from Vue single file components into composables, a refactor to add Pinia, frame to parent communication, and a synced basic style are all marked done. A button of Edit this page is done, as is embedding the Nuxt docs, with the note about updating CORS headers.

The open items are what tell you the state of the content. The content section itself is unchecked, with Allow each guide to configure file filter, Persist user changes when toggling solutions and Verification for tutorial tasks all still open. An About Page, a Welcome Screen and a note to try the splitter component from ark-ui.com are open too.

So the machinery is largely in place and the course writing is what lags. If you come here for the tooling pattern, it is worth studying. If you come for a complete guided course, the repository tells you plainly that it is not one yet.

Running it locally, and the state of the repository

Local development is a short sequence. You need Node.js v22.0 or newer and pnpm installed, then after cloning the repository you install dependencies with:

pnpm install

And start the development server with:

pnpm dev

The development server runs at http://localhost:3000. The requirement on Node 22 is a hard floor rather than a suggestion, which fits a stack that includes a browser-side Node environment and current Nuxt tooling.

The repository also has a .github/ directory, a .vscode/ directory, CODEOWNERS, an eslint.config.js at the root, and an .editorconfig-style .gitignore. The presence of CODEOWNERS and the split between a main branch and the work-in-progress framing suggests an active review process rather than a solo experiment, even though the build was streamed publicly.

The last push was on 2026-04-09. There are no GitHub releases, so the history of the project is the commit log. The licence is MIT, and the LICENSE file is in the repository root.

One more point about the streaming development model. The videos of the full build process are a genuine alternative to reading the code if you want to understand why a choice was made, and the tutorial site itself is the better route if you want to see the finished behaviour. The code is there to be read, and the project explicitly asks for contributions, with a separate note for translators.

Editorial conclusion

learn.nuxt.com suits a Nuxt developer who learns by editing real files in a running project rather than by reading snippets, and the WebContainer approach means the tutorial exercises the actual toolchain including the terminal and the dev server. It does not suit you as a reference to look up a specific API, since the content is unfinished and the roadmap still lists the tutorial content itself as open work, and it does not suit a team that needs offline or self-hosted instruction. Before you rely on it, read the guide you care about in full and check its status, and note that the last push was on 2026-04-09, so features listed as done in the repository roadmap may still be in flux.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nuxt/learn.nuxt.com on GitHub
4. Project website
5. README