Nuxt 3.10

v3.10 comes quite close on the heels of v3.9, but it's packed with features and fixes. Here are a few highlights.

✨ Experimental shared asyncData when prerendering

When prerendering routes, we can end up refetching the same data over and over again. In Nuxt 2 it was possible to create a 'payload' which could be fetched once and then accessed in every page (and this is of course possible to do manually in Nuxt 3 - see this article).

With #24894, we are now able to do this automatically for you when prerendering your site. Your useAsyncData and useFetch calls will be deduplicated and cached between renders of your site.

export defineNuxtConfig({ 
  experimental: { 
    sharedPrerenderData: true
  } 
})

🆔 SSR-safe accessible unique ID creation

We now ship a useId composable for generating SSR-safe unique IDs (#23368). This allows creating more accessible interfaces in your app. For example:

<script setup>
const emailId = useId()
const passwordId = useId()
</script>

<template>
  <form>
    <label :for="emailId">Email</label>
    <input
      :id="emailId"
      name="email"
      type="email"
    >
    <label :for="passwordId">Password</label>
    <input
      :id="passwordId"
      name="password"
      type="password"
    >
  </form>
</template>

✍️ Extending app/router.options

It's now possible for module authors to inject their own router.options files (#24922). The new pages:routerOptions hook allows module authors to do things like add custom scrollBehavior or add runtime augmenting of routes.

Client-side Node.js support

We now support (experimentally) polyfilling key Node.js built-ins (#25028), just as we already do via Nitro on the server when deploying to non-Node environments.

That means that, within your client-side code, you can import directly from Node built-ins (node: and node imports are supported). However, nothing is globally injected for you, to avoid increasing your bundle size unnecessarily. You can either import them where needed.

import { Buffer } from 'node:buffer'
import process from 'node:process'

Or provide your own polyfill, for example, inside a Nuxt plugin.

import { Buffer } from 'node:buffer'
import process from 'node:process'

globalThis.Buffer = Buffer
globalThis.process = process

export default defineNuxtPlugin({})

This should make life easier for users who are working with libraries without proper browser support. However, because of the risk in increasing your bundle unnecessarily, we would strongly urge users to choose other alternatives if at all possible.

🍪 Better cookie reactivity

We now allow you to opt-in to using the CookieStore. If browser support is present, this will then be used instead of a BroadcastChannel to update useCookie values reactively when the cookies are updated (#25198).

This also comes paired with a new composable, refreshCookie which allows manually refreshing cookie values, such as after performing a request.

🏥 Detecting anti-patterns

In this release, we've also shipped a range of features to detect potential bugs and performance problems.

• We now will throw an error if setInterval is used on server (#25259).
• We warn (in development only) if data fetch composables are used wrongly (#25071), such as outside of a plugin or setup context.
• We warn (in development only) if you are not using <NuxtPage /> but have the vue-router integration enabled (#25490). (<RouterView /> should not be used on its own.)

🧂 Granular view transitions support

It's now possible to control view transitions support on a per-page basis, using definePageMeta (#25264).

You need to have experimental view transitions support enabled first:

export default defineNuxtConfig({
  experimental: {
    viewTransition: true
  },
  app: {
    // you can disable them globally if necessary (they are enabled by default)
    viewTransition: false
  }
})

And you can opt in/out granularly:

<script setup lang="ts">
definePageMeta({
  viewTransition: false
})
</script>

Finally, Nuxt will not apply View Transitions if the user's browser matches prefers-reduced-motion: reduce (#22292). You can set viewTransition: 'always'; it will then be up to you to respect the user's preference.

🏗️ Build-time route metadata

It's now possible to access routing metadata defined in definePageMeta at build-time, allowing modules and hooks to modify and change these values (#25210).

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

Please, experiment with this and let us know how it works for you. We hope to improve performance and enable this by default in a future release so modules like @nuxtjs/i18n and others can provide a deeper integration with routing options set in definePageMeta.

📦 Bundler module resolution

With #24837, we are now opting in to the TypeScript bundler resolution which should more closely resemble the actual way that we resolve subpath imports for modules in Nuxt projects.

'Bundler' module resolution is recommended by Vue and by Vite, but unfortunately there are still many packages that do not have the correct entries in their package.json.

As part of this, we opened 85 PRs across the ecosystem to test switching the default, and identified and fixed some issues.

If you need to switch off this behaviour, you can do so. However, please consider raising an issue (feel free to tag me in it) in the library or module's repo so it can be resolved at source.

export default defineNuxtConfig({
  future: {
    typescriptBundlerResolution: false
  }
})

✅ Upgrading

As usual, our recommendation for upgrading is to run:

nuxi upgrade --force

This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.

Full Release Notes

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 ✨