263> unhead v3 introduces type-narrowing for useHead, which can be a **breaking type change** if you were relying on the looser v2 types. The runtime behaviour is compatible for the vast majority of apps, and promise input (deprecated in v2) is no longer supported. If you hit type errors after upgrading, they're almost always genuine tightening rather than regressions.
263> unhead v3 introduces type-narrowing for useHead, which can be a **breaking type change** if you were relying on the looser v2 types. The runtime behaviour is compatible for the vast majority of apps, and promise input (deprecated in v2) is no longer supported. If you hit type errors after upgrading, they're almost always genuine tightening rather than regressions.
|> unhead v3 introduces type-narrowing for useHead, which can be a **breaking type change** if you were relying on the looser v2 types. The runtime behaviour is compatible for the vast majority of apps, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=help: The notes give no migration. Check your useHead calls for promise input and pass resolved values instead.
Kernpunkte
note[1]:Nuxt now runs on Vite 8, which brings faster cold starts and upstream improvements.release-notes:30
note[2]:An experimental SSR streaming mode can improve Time to First Byte by flushing the HTML shell early.release-notes:60
note[3]:Warnings and errors now carry stable codes, with an explanation of why they happened and a fix to try.release-notes:96
note[4]:A reactive enabled option in useFetch and useAsyncData can gate data fetching until a condition is met.release-notes:157
release-notesgithub.com/nuxt/nuxt · 604 Zeilen
> 4.5.0 is the next minor release.
## 📣 Some News
#### Preparing for Nuxt 5
A good chunk of this release is (hopefully) invisible plumbing for Nuxt 5. We've moved onto the latest major versions of several core dependencies (`unhead` v3, `unctx` v3, and Vite 8), switched the framework's own build over to [`tsdown`](https://github.com/nuxt/nuxt/pull/35179), and introduced a stable `nuxt/*` build output contract with dev exports so that type-checking in the Nuxt monorepo works without a build step (#35463, #35605).
Much of this is working to shrink the gap between v4 and v5 internally, so that the migration will be as boring as possible.
> [!TIP]
> If you want to test some of the breaking changes of Nuxt v5, you can already opt in with `future.compatibilityVersion: 5`. Keep an eye on the [Upgrade Guide](https://nuxt.com/docs/getting-started/upgrade) for details as they land.
With the release of Nuxt v4.5, our focus as a team will turn to stabilising Nuxt v5 and creating compatibility utilities to make the upgrade as smooth as possible.
#### Nuxt 3 End-of-Life
Nuxt 3 reaches end-of-life on **July 31, 2026**, so this is one of the last few 3.x releases we'll ship. If you're still on v3, now is a great time to move across. Most people told us the v3 to v4 upgrade was smooth, and we've kept the [upgrade guide](https://nuxt.com/docs/getting-started/upgrade) up to date.
Alongside v4.5.0 we're publishing a maintenance patch for the 3.x line (**v3.21.9**) with the compatible bug fixes and smaller improvements from this release backported. The headline items here (Vite 8, Rspack 2, `unhead` v3, `unctx` v3) are major upgrades and stay v4-only, so 3.x remains stable as it approaches end-of-life.
## 👀 Highlights
Nuxt 4.5 is a big one. This release ships three major upgrades to the build layer (Vite 8, Rspack 2, and a brand new Rsbuild-powered pipeline for the Rspack builder), an experimental SSR streaming mode, a handful of new composables and conventions, and a lot of groundwork that brings us closer to Nuxt 5.
There's a lot here, so grab a coffee. ☕️
### ⚡️ Vite 8
Nuxt now runs on [Vite 8](https://vite.dev) (#34256). This brings faster cold starts, the latest Rolldown-powered internals, and many upstream improvements from the Vite team.
For most apps this is a transparent upgrade. If you have custom Vite plugins or config, it's worth skimming the [Vite migration guide](https://vite.dev/guide/migration) to check for anything that affects you.
> [!WARNING]
> Vite 8 is a major version bump. If you depend on Vite directly (custom plugins, `vite.config` tweaks, or ecosystem plugins that pin a Vite version), make sure those are compatible before upgrading in production.
### 🦀 Rspack 2 and Rsbuild
If you use the Rspack builder, this release is a substantial upgrade. We've moved to [Rspack 2](https://www.rspack.dev/blog/announcing-2-0) (#34929), which is faster and lighter, and rebuilt the builder on top of [`@rsbuild/core`](https://rsbuild.dev) (#35489).
The public surface stays the same. You still opt in with `builder: 'rspack'` and the existing `rspack:*` hooks continue to work:
```ts
// nuxt.config.ts
export default defineNuxtConfig({
builder: 'rspack',
})
```
Under the hood, though, a lot has changed for the better:
- The dev server now runs in middleware mode via Rsbuild, replacing `webpack-dev-middleware` and `webpack-hot-middleware` (#35575).
- We use an Rspack-specific Vue loader for correct SSR scoped-style ids and stricter ESM resolution (#35566).
> [!NOTE]
> This is the foundation for first-class Rsbuild support. We kept the builder named `rspack` for now so nothing breaks, but the internals are now Rsbuild all the way down.
### 🌊 Experimental SSR Streaming
This is one I'm particularly excited about. You can now enable **SSR streaming** to dramatically improve Time to First Byte (#34411). Instead of buffering the whole rendered page and sending it in one go, Nuxt flushes the HTML shell (your `<head>`, styles, preload hints, and entry scripts) immediately, then streams the body as Vue renders it.
```ts
// nuxt.config.ts
export default defineNuxtConfig({
experimental: {
ssrStreaming: true,
},
})
```
Streaming is automatically disabled for bots and crawlers so search engines still receive fully-rendered HTML. You can tune which user agents count as crawlers, and you can opt individual routes out:
There's one thing worth understanding before you turn it on. Because streaming commits the HTTP status and headers with the very first byte, anything that mutates the response *after* rendering has begun (a `setResponseStatus()` in a `<script setup>`, a cookie write during middleware, and so on) can't reach the client. Nuxt handles the common cases for you: routes with `redirect`, `cache`, `isr`, `swr`, `noScripts`, or `ssr: false` rules automatically fall back to the buffered renderer, and in development we log a warning naming any dropped mutations so nothing fails silently.
> [!WARNING]
> SSR streaming is experimental and off by default. It could be great for content-heavy routes where TTFB matters, but test it against your app's response-mutating logic (status codes, headers, cookies) before shipping it widely. The [experimental features docs](https://nuxt.com/docs/guide/going-further/experimental-features#ssrstreaming) cover the fallback rules and caveats in detail.
This one I'm really happy about. Nuxt now has a **stable error code system** (#35429). Warnings and errors raised during build and at runtime now carry a stable code (like `NUXT_E1001` or `NUXT_B5001`), a short explanation of **why** it happened, and a concrete **fix** to try.
Every code is greppable and bookmarkable, and the ones that need more than a one-line fix link straight to a dedicated docs page. For example, the classic "a composable was called outside a Nuxt context" now surfaces as `NUXT_E1001` with the why/fix inline and a [docs page](https://nuxt.com/docs/errors/e1001) explaining the context rules and how to use `runWithContext()`.
To keep production output lean, the verbose why/fix text is stripped from production builds, leaving just the stable code.
This is the foundation for much better error messages across Nuxt, and we'll keep migrating existing warnings and errors onto it over the coming releases. If you've ever squinted at a cryptic Nuxt message, this is for you.
### 🎨 `useLayout` Composable
There's a new `useLayout` composable for reading the layout that's been resolved for the current route (#35623). Previously there was no clean, reactive way to ask "which layout is this page using?" from within a component.
```vue
<!-- app/components/LayoutBadge.vue -->
<script setup lang="ts">
const layout = useLayout()
</script>
<template>
<span>Current layout: {{ layout }}</span>
</template>
```
It returns a read-only computed ref, so it stays in sync as you navigate or as route rules and `definePageMeta` change the resolved layout.
Nuxt now supports **named views** through a filename convention (#35123). If a parent page renders more than one `<NuxtPage>` outlet, you can give each outlet a name and provide a sibling page file for it using the `name@view.vue` convention:
```bash
# Directory Structure
-| pages/
---| parent/
-----| child.vue
-----| child@sidebar.vue
---| parent.vue
```
```vue
<!-- pages/parent.vue -->
<template>
<div>
<NuxtPage />
<aside>
<NuxtPage name="sidebar" />
</aside>
</div>
</template>
```
Navigating to `/parent/child` renders `child.vue` into the default outlet and `child@sidebar.vue` into the `sidebar` outlet. This has actually been possible in Vue Router for a long time; this release wires it up to Nuxt's file-based routing.
> [!NOTE]
> `definePageMeta` is read from the default route file only, and per-view rendering modes aren't supported (the parent page's mode applies to the default view).
### 🚦 `enabled` Option for `useFetch` and `useAsyncData`
You can now gate data fetching with a reactive `enabled` option ([#33260](https://github.com/nuxt/nuxt/pull/33260)). While `enabled` is `false`, every execution is blocked (the initial fetch, `execute`/`refresh`, and watch triggers), and if you flip it from `true` to `false` mid-flight, the in-flight request is cancelled without clearing your existing `data`.
```vue [app/pages/search.vue]
<script setup lang="ts">
const query = ref('')
const { data } = await useFetch('/api/search', {
query: { q: query },
// Only fetch once the user has typed something
enabled: () => query.value.length > 2,
})
</script>
```
This is perfect for dependent or conditional queries, where you don't want to fire a request until some precondition is met. It pairs naturally with a getter or a ref, so it stays reactive.
### 🔗 `NuxtLink` Prefetch Control for Custom Slots
When you use `<NuxtLink>` with the `custom` prop, Nuxt no longer attaches prefetch handlers for you, because it can't know how you've structured your markup. To make that ergonomic, the slot now exposes everything you need to wire prefetching up yourself (#34539):
You get `prefetch` to trigger it, `prefetched` to know whether it's already happened (great for a prefetched class), and `shouldPrefetch` to respect the user's connection and config.
Here's another one we'd love you to try. When you prefetch a link to a route with payload extraction, Nuxt already primes the destination's data and chunks. With the new opt-in `experimental.prefetchPreloadTags` (#35144), it also forwards the destination's `<link rel="preload">` and `modulepreload` hints (whatever the page sets via `useHead`, or via modules like `@nuxt/image`'s `<NuxtImg preload>`) into the *current* document, downgraded to `rel="prefetch"` so they don't compete with the resources the user is looking at right now.
```ts
// nuxt.config.ts
export default defineNuxtConfig({
experimental: {
prefetchPreloadTags: true,
},
})
```
The practical effect is that heavy above-the-fold assets on the *next* page (a hero image, a critical script) start downloading while the user is still on the current one, so the navigation feels instant. It's off by default while we gather feedback, so please give it a spin and tell us how it behaves on your app.
### 🌐 `import.meta.envName`
The resolved Nuxt environment name is now available at runtime as `import.meta.envName` for both Vite and webpack/Rspack builds (#34844). This is the value set by `--envName` (or the resolved default), so you can branch on it in your app code:
Nuxt now publishes [diagnostics-channel](https://nodejs.org/api/diagnostics_channel.html) traces for its server-side subsystems (#35191). It's unopinionated: we emit `nuxt.render`, `nuxt.island`, `nuxt.data`, and `nuxt.plugin` channels following the [untracing](https://github.com/unjs/untracing) naming convention, and you can build OpenTelemetry (or anything else) on top. It works in Node, Deno, Bun, and Cloudflare Workers.
```ts
// nuxt.config.ts
export default defineNuxtConfig({
// Turn on Nuxt's own channels
tracingChannel: true,
})
```
You can also enable it granularly. In Nuxt v5, there will be additional Nitro-level channels:
```ts
// nuxt.config.ts
export default defineNuxtConfig({
tracingChannel: {
nuxt: true,
},
})
```
> [!NOTE]
> Channel names, payload shapes, and option keys may still change while the [untracing](https://github.com/unjs/untracing) registry settles.
### 📦 Dependency Upgrades
#### `unhead` v3
Nuxt's head management now runs on [`unhead` v3](https://unhead.unjs.io/docs/releases/v3) (#34793). It's smaller, uses a synchronous engine internally, and ships better type-safety for `useHead` out of the box. This also unblocks SSR streaming.
> [!WARNING]
> `unhead` v3 introduces type-narrowing for `useHead`, which can be a **breaking type change** if you were relying on the looser v2 types. The runtime behaviour is compatible for the vast majority of apps, and promise input (deprecated in v2) is no longer supported. If you hit type errors after upgrading, they're almost always genuine tightening rather than regressions.
#### `unctx` v3
We've moved to [`unctx` v3](https://github.com/unjs/unctx) (#35541), which resolves a class of long-standing async context issues (#33644). This is part of the composable-context reliability work that continues into v5.
#### And more
We've also updated `magic-string` to v1, Babel to v8, and pulled in the latest Rolldown across the board. Running `nuxt upgrade --dedupe` (see below) is the easiest way to pull these through cleanly.
### 🛠️ Nuxt CLI
This release bundles some improvements from `@nuxt/cli` v3.36 and v3.37:
- **`nuxt module remove`** to uninstall a module and clean up its config ([nuxt/cli#1306](https://github.com/nuxt/cli/pull/1306)), the natural companion to `nuxt module add`.
- **Non-interactive `nuxt init`** for scripting and CI ([nuxt/cli#1341](https://github.com/nuxt/cli/pull/1341)), plus it now respects the template's own package manager instead of prompting ([nuxt/cli#1330](https://github.com/nuxt/cli/pull/1330)).
- **Type-check onboarding**: `nuxt typecheck` now offers to install `vue-tsc` and `typescript` for you if they're missing ([nuxt/cli#1316](https://github.com/nuxt/cli/pull/1316)).
- **Golar support for type-checking**: `nuxt typecheck` can now use [Golar](https://golar.dev) as an alternative to `vue-tsc` ([nuxt/cli#1362](https://github.com/nuxt/cli/pull/1362)). It's picked up automatically if it's installed (or a `golar.config.*` file exists), and you can force a checker with `--checker=vue-tsc` or `--checker=golar`:
```sh
nuxt typecheck --checker=golar
```
- **Layer-aware dev server**: the dev server now reloads on changes to local layer `nuxt.config` files ([nuxt/cli#1345](https://github.com/nuxt/cli/pull/1345)).
### 🧩 TypeScript Plugin and Named Layout Slots
Nuxt's experimental TypeScript plugin is powered by [`@dxup/nuxt`](https://github.com/KazariEX/dxup), and this release bundles a newer version of it. If you haven't tried it, turning on `experimental.typescriptPlugin` gives you a set of editor niceties: renaming an auto-imported component updates every usage, plus go-to-definition for glob imports, Nitro routes, `definePageMeta`, `runtimeConfig`, and typed route names.
New in the bundled version is an opt-in **runtime** feature: named layout slots ([KazariEX/dxup#20](https://github.com/KazariEX/dxup/pull/20)). You can write a top-level named-slot template in a page and have it forwarded into the matching named slot of the active layout. That lets a page inject content into its layout's slots, which file-based layouts don't otherwise allow.
As always, a lot of work has gone into making Nuxt faster and steadier.
One you can opt into today is the **shared file watcher** (#35143). Vite already runs a chokidar-based watcher, so Nuxt can piggy-back on it instead of spinning up a second one, using less memory and fewer file handles. This becomes the default with `compatibilityVersion: 5`, but you can turn it on now and let us know how it goes:
```ts
// nuxt.config.ts
export default defineNuxtConfig({
experimental: {
watcher: 'builder',
},
})
```
There are also some other good performance improvements that don't need to be opted into:
- **Faster dev startup**: dev-only Nitro and pages work is now deferred and streamlined (#35381, #35383).
- **Leaner production builds**: the island-renderer chunk is skipped entirely when you use no islands (#35456), and plugin handling is tree-shaken out of prod builds (#35278).
- **Improved island hashing**: more stable island and key hashing, with `getIslandHash` and `hashKey` now exposed (#35583).
- **Concurrency and I/O wins** across Kit path resolution and Nitro inline styles (#35511, #35514).
A couple of other nice quality-of-life fixes:
- `$fetch` is now auto-imported in user code, which fixes edge cases with top-level `$fetch.create` under Rolldown's output format (#35581).
- Nuxt now honours system `HTTP_PROXY` / `HTTPS_PROXY` environment variables in the builder environment (#35183).
- HMR now works for `defineNuxtComponent` in JSX (#35620).
### ⚠️ Heads-Up Before Upgrading
As mentioned above, this release includes three major dependency bumps. For most apps they're transparent, but they're worth a moment of attention:
- **Vite 8**: check custom Vite plugins and config against the [Vite migration guide](https://vite.dev/guide/migration).
- **Rspack 2**: if you use `builder: 'rspack'`, the internals are now Rsbuild-based, so custom Rspack config may need review.
- **`unhead` v3**: possible breaking *type* changes from stricter `useHead` typing.
### ⬆️ Upgrading
Our recommendation for upgrading is to run:
```sh
npx nuxt upgrade --dedupe
# or, if you are staying on the 3.x line
npx nuxt@latest upgrade --dedupe --channel=v3
```
This will deduplicate your lockfile and help ensure you pull in updates from the other dependencies Nuxt relies on, particularly across the unjs ecosystem (which matters more than usual this release, given the major bumps).
> [!TIP]
> Check out our [upgrade guide](https://nuxt.com/docs/getting-started/upgrade) if you're upgrading from an older version.
Thank you to all of the many contributors to this release. This was a big one, and it wouldn't happen without you. 💚