We're excited to announce Nuxt 4.2, bringing new capabilities for better TypeScript DX, enhanced error handling, and improved control over data fetching! 🎉

🎯 Abort Control for Data Fetching

You can now use AbortController signals directly within useAsyncData, giving you fine-grained control over request cancellation (#32531).

This works by passing an internal signal to your useAsyncData handler to cancel any promise that can be canceled, such as $fetch.

<script setup lang="ts">
const { data, error, clear, refresh } = await useAsyncData('users', (_nuxtApp, { signal }) => $fetch('/api/users', {
  signal
}))

refresh() // will actually cancel the $fetch request (if dedupe: cancel)
  
clear() // will cancel the latest pending handler
</script>

You also pass an AbortController signal directly to refresh/execute, giving you fine-grained control over request cancellation. This is particularly useful when you need to abort requests based on user actions or component lifecycle events.

const { data, refresh } = await useAsyncData('posts', fetchPosts)

// Abort an ongoing refresh
const abortController = new AbortController()
refresh({ signal: abortController.signal })

// Later...
abortController.abort()

🎨 Better Error Pages in Development

When an error occurs during development, Nuxt will now display both your custom error page and a detailed technical error overlay (#33359). This gives you the best of both worlds – you can see what your users will experience while also having immediate access to stack traces and debugging information.

The technical overlay appears as a toggleable panel that doesn't interfere with your custom error page, making it easier to debug issues while maintaining a realistic preview of your error handling.

🔮 Opt-in Vite Environment API

For those wanting to experiment with cutting-edge features, you can now opt into the Vite Environment API (#33492).

The Vite Environment API is a major architectural improvement in Vite 6. It closes the gap between development and production by allowing the Vite dev server to handle multiple environments concurrently (rather than requiring multiple Vite dev servers, as we have done previously in Nuxt).

This should improve performance when developing and eliminate some edge case bugs.

... and it is the foundation for implementing Nitro as a Vite environment, which should speed up the dev server still further, as well as allowing more greater alignment in development with your Nitro preset.

export default defineNuxtConfig({
  experimental: {
    viteEnvironmentApi: true
  }
})

This is also the first breaking change for Nuxt v5. You can opt in to these breaking changes by setting compatibilityVersion to 5:

export default defineNuxtConfig({
  future: {
    compatibilityVersion: 5
  },
})

Please only use this for testing, as this opts in to unlimited future breaking changes, including updating to Nitro v3 once we ship the Nuxt integration.

This is highly experimental and the API may change. Only enable if you're prepared for potential breaking changes and want to help shape the future of Nuxt!

📦 New @nuxt/nitro-server Package

We've extracted Nitro server integration into its own package: @nuxt/nitro-server (#33462). This architectural change allows for different Nitro integration patterns and paves the way for future innovations in server-side rendering.

While this change is mostly internal, it's part of our ongoing effort to make Nuxt more modular and flexible. The new package provides standalone Nitro integration and sets the foundation for alternative integration approaches (such as using Nitro as a Vite plugin in Nuxt v5+).

This is an internal refactor – no changes should be required in your code.

⚡ Performance Improvements

We've also shipped several performance enhancements:

• Precomputed renderer dependencies – We now compute renderer dependencies at build time rather than runtime, improving cold start and initial render performance (#33361)
• Reduced dependencies – Removed unnecessary dependencies from kit and schema packages (7ae2cf563)

📉 Async Data Handler Extraction

One of the most exciting performance improvements is the new experimental async data handler extraction (#33131). When enabled, handler functions passed to useAsyncData and useLazyAsyncData are automatically extracted into separate chunks and dynamically imported.

This is particularly effective for prerendered static sites, as the data fetching logic is only needed at build time and can be completely excluded from the client bundle.

In testing with a previous version of nuxt.com, this feature reduced JavaScript bundle size by 39%! Of course, your mileage may vary depending on how much data fetching logic you have.

<script setup lang="ts">
// This handler will be extracted into a separate chunk
// and only loaded when needed
const { data: post } = await useAsyncData('post', async () => {
  const content = await queryContent(`/blog/${route.params.slug}`).findOne()
  
  // Complex data processing that you don't want in the client bundle
  const processed = await processMarkdown(content)
  const related = await findRelatedPosts(content.tags)
  
  return {
    ...processed,
    related
  }
})
</script>

For static/prerendered sites, enable it in your config:

export default defineNuxtConfig({
  experimental: {
    extractAsyncDataHandlers: true
  }
})

The extracted handlers are then tree-shaken from your client bundle when prerendering, as the data is already available in the payload. This results in significantly smaller JavaScript files shipped to your users.

🔧 Experimental TypeScript Plugin Support

We're introducing experimental support for enhanced TypeScript developer experience through the @dxup/nuxt module.

This module adds a number of TypeScript plugins that aim to improve your experience when using Nuxt-specific features:

• Smart component renaming: Automatically updates all references when you rename auto-imported component files
• Go to definition for dynamic imports: Navigate directly to files when using glob patterns like import(`~/assets/${name}.webp`)
• Nitro route navigation: Jump to server route handlers from data fetching functions ($fetch, useFetch, useLazyFetch)
• Runtime config navigation: Go to definition works seamlessly with runtime config properties
• Enhanced auto-import support: Includes the @dxup/unimport plugin for better navigation with auto-imported composables and utilities

To enable this feature, set experimental.typescriptPlugin to true in your Nuxt configuration:

export default defineNuxtConfig({
  experimental: {
    typescriptPlugin: true
  }
})

Once enabled, the module will be automatically installed and configured by Nuxt.

This feature also requires selecting the workspace TypeScript version in VS Code. Run the "TypeScript: Select TypeScript Version" command and choose "Use Workspace Version".

🎁 Other Improvements

• Component declarationPath – You can now specify a custom declaration path for components (#33419)
• Module resolution extensions – Kit's resolveModule now accepts an extensions option (#33328)
• Global head utility – New setGlobalHead utility in kit for easier head management (#33512)

🩹 Important Fixes

• Route hash is now preserved when redirecting based on routeRules (#33222)
• Fixed concurrent calls to loadNuxtConfig with proper cleanup (#33420)
• Object-format href now works correctly in <NuxtLink> (c69e4c30d)
• Component auto-imports now work as arguments to Vue's h() function (#33509)
• Fixed app config array handling during HMR (#33555)

✅ Upgrading

Our recommendation for upgrading is to run:

npx nuxt upgrade --dedupe

This will refresh your lockfile and pull in all the latest dependencies that Nuxt relies on, especially from the unjs ecosystem.

👉 Full Release Notes

Read the full release notes of Nuxt v4.2.0.

Thank you for reading this far! We hope you enjoy the new release. Please do let us know if you have any feedback or issues.

Happy Nuxting ✨