# Nuxt: two release lines, one playground, and a four stage test gate

> Nuxt is the full-stack Vue framework, MIT licensed and self-hosting its own development environment in a playground app. Two version lines shipped on the same day in August 2026, and the framework's test command chains four suites into one gate, so both the version you pick and the suite you run decide how a change lands.

**nuxt/nuxt** — Nuxt is a free, open-source full-stack Vue framework offering server-side rendering, static generation and hybrid modes with auto imports and zero-config TypeScript.

- Repository: https://github.com/nuxt/nuxt
- Website: https://nuxt.com
- Stars: 60,902 · Forks: 5,801
- Language: TypeScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/nuxt-nuxt

## One command creates the project, and nuxt.new opens one in a browser

A starter project comes from a single command, with the project name left as an argument:

```bash
npm create nuxt@latest <my-project>
```

That scaffold is described as creating a project with all the necessary files and dependencies, so the starting point is a working tree rather than a template you assemble. If you do not want a local directory at all, nuxt.new opens a starter on CodeSandbox or StackBlitz, or locally, which is the shortest path to seeing the framework run. What the scaffold buys you is visible in the first component you write:

```vue
<script setup lang="ts">
useSeoMeta({
  title: 'Meet Nuxt',
  description: 'The Intuitive Vue Framework.',
})
</script>
```

That is the whole script block of the example app.vue. The template below it uses AppHeader, AppFooter and NuxtPage with no import statements, which is what the auto-imports of components, composables and utils mean in practice, and the meta title and description are set through useSeoMeta rather than a head manager you configure yourself.

## v4.5.2 and v3.21.11 were published on the same afternoon

The release list is the first thing to read, and it has three entries: v4.5.2, v3.21.11, both dated 2026-08-05, and v4.5.1 dated 2026-07-27. Two major lines are therefore still receiving patches at the same time, which is unusual for a framework and has a direct effect on how you start a project. npm create nuxt@latest gives you the current line, while a maintenance line is being fixed on the same day, and the documentation links embedded in the README point at the 4.x path for bug reports, contributions and getting help. The consequence is that version choice is a decision you make on day one and revisit later, not something the starter handles for you. A team mid-migration is running one of these two lines, and the difference between them is where you should spend the reading time.

## The development loop runs against playground/, not against a test

The scripts show how the framework is worked on. dev is pnpm play, and play is nuxt dev playground, so a bare development start boots a real Nuxt app from the playground directory. The same pattern repeats for the other modes: play:build is nuxt build playground, play:generate is nuxt generate playground, and play:preview is nuxt preview playground. That is a deliberate arrangement. The framework dogfoods itself, so a change to the runtime is observed in a full application before any assertion runs against it. For a contributor the consequence is that the playground is the first place a regression shows up, and for a reader comparing targets it is a hint about how they differ: the same playground can be built, generated or previewed, and those are the static and server paths sitting next to each other in the scripts. nuxt.config.ts at the repository root belongs to the framework's own build, not to your project.

## A stale jiti cache is the failure mode the debug script exists for

There is one script in the manifest that exists purely to clear a cache: debug:dev removes the jiti cache under node_modules and then runs pnpm nuxt dev. Its presence tells you that the development server compiles through a cache, and that a wrong fix which is not your code is a known enough problem to get its own command. The same pattern shows up in the regular scripts, where dev:prepare is nuxt prepare, and both lint and lint:fix begin with pnpm dev:prepare before eslint runs. So type generation is not implicit in this project, it is an explicit step that lint, test and the editor all depend on. If you skip it, the errors you see are about missing types rather than about the change you made. The repository also carries knip.json, renovate.json and .nuxtrc, which is the trio you would expect from a codebase that treats unused exports and dependency bumps as CI failures.

## The test command is four suites, and one failure stops the rest

test is pnpm test:prepare && vitest run && pnpm test:types && pnpm typecheck, so preparing fixtures, running vitest, checking fixture types and running a project-wide typecheck happen in sequence and a failure in any of them ends the command. Underneath sit narrower targets. test:runtime names its vitest projects explicitly: nuxt, nuxt-universal, nuxt-legacy, nuxt-dev, nuxt-insensitive and nuxt-sensitive. The last three names are informative, because nuxt-legacy means an older build stays in the matrix, and nuxt-insensitive and nuxt-sensitive mean the same behaviour is verified under both file system case settings. test:fixtures runs the fixtures projects, and test:fixtures:dev and test:fixtures:webpack split them further, so both bundlers are covered. The practical cost for a contributor is that this is not a fast loop, and the practical benefit is that a case sensitivity bug cannot reach a release.

## Four rendering targets, and no single build command for all of them

The feature list names server-side rendering, static site generation, hybrid rendering and edge-side rendering as separate capabilities, which is the honest description of what you are adopting. Below that sit automatic routing with code-splitting and pre-fetching, data fetching and state management, search engine optimization and meta tags, and a server/ directory for going full-stack. Every one of those is a decision with a cost attached, and the mode you pick changes the artefact you deploy. The playground scripts make the split concrete, since the same directory can be built with nuxt build, generated with nuxt generate, or previewed afterwards. What the README does not do is tell you which mode suits which hosting platform; that mapping is left to the deployment documentation linked from the feature list, and to the 300+ modules for anything the core does not cover.

## A private pnpm workspace, even though the starter command is npm

The repository manifest is named nuxt-framework and sets private to true, with type module and licence MIT, so this is a workspace root rather than something you install. The workspace itself is pnpm based: pnpm-workspace.yaml and pnpm-lock.yaml at the root, a packages directory, and build running a filtered pnpm build across everything under that directory. The mismatch with the npm command in the starter is deliberate and harmless for users, since a generated project installs its own dependencies, but it tells you the framework is built with a different tool than the one it asks you to start with. Contributing also has its own surface: CONTRIBUTING.md, CODEOWNERS, SECURITY.md, AGENTS.md and CLAUDE.md sit at the top level, prepare runs simple-git-hooks, and the documentation has its own gate in lint:docs, which chains markdownlint, case-police, a link checker script and eslint over docs.

## Conclusion

Choose Nuxt when your team already writes Vue and you want server rendering, static generation or a hybrid of the two without assembling the routing, data fetching and meta tag layer by hand. Choose something else if you need a single obvious command that produces one artefact for one target, because Nuxt names four rendering modes and the choice between them is a deployment decision you own. Verify three things before you start. Which line you pin, since v4.5.2 and v3.21.11 were both published on 2026-08-05 and the documentation links in the README point at the 4.x path. Whether the module you need is one of the 300+ listed, since that list is the extension path the project points you at. And that your editor understands TypeScript with zero configuration, because the framework generates its own types through nuxt prepare and a stale jiti cache will make you debug the wrong problem.

## FAQ

### What is Nuxt used for?

It is the full-stack Vue framework, used to build server rendered, statically generated, hybrid or edge rendered applications. It also handles automatic routing with code-splitting and pre-fetching, data fetching, meta tags and auto-imports of components, composables and utils.

### Is Nuxt free to use?

Yes. The repository carries the MIT licence and the README links the MIT licence text. There is no paid edition mentioned; commercial support is offered separately through the Nuxt Experts and agency partner pages.

### What is the difference between nuxt generate and nuxt build?

Both appear in the framework's own scripts against the same playground directory: play:build runs nuxt build playground and play:generate runs nuxt generate playground. Static site generation and server-side rendering are named as separate capabilities in the feature list, and the deployment documentation covers which hosting target suits each.

### Should I start on Nuxt 3 or Nuxt 4?

Both lines are still being patched: v4.5.2 and v3.21.11 were published on 2026-08-05, with v4.5.1 on 2026-07-27. The documentation links in the README point at the 4.x path, so read the difference between the two lines before pinning one for a long lived project.

### Is it called Nuxt or Nuxt.js?

The project brands itself Nuxt and the homepage is nuxt.com, with documentation under nuxt.com/docs. A new project is created with npm create nuxt@latest, and there is a separate Nuxt UI module listed among the modules rather than a second framework name.

## Sources

- [Official documentation](https://nuxt.com)
- [Official README](https://github.com/nuxt/nuxt#readme)
- [Project repository](https://github.com/nuxt/nuxt)
- [Release notes](https://github.com/nuxt/nuxt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nuxt-nuxt