We're excited to announce Nuxt 4.2, bringing new capabilities for better TypeScript DX, enhanced error handling, and improved control over 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)
refresh() // will actually cancel the $fetch request (if dedupe: cancel)
refresh()
  
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()
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.
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.
@nuxt/nitro-server PackageWe'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+).
We've also shipped several performance enhancements:
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.
<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.
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:
import(`~/assets/${name}.webp`)$fetch, useFetch, useLazyFetch)@dxup/unimport plugin for better navigation with auto-imported composables and utilitiesTo 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.
declarationPath – You can now specify a custom declaration path for components (#33419)resolveModule now accepts an extensions option (#33328)setGlobalHead utility in kit for easier head management (#33512)routeRules (#33222)loadNuxtConfig with proper cleanup (#33420)href now works correctly in <NuxtLink> (c69e4c30d)h() function (#33509)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.
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 ✨