# Source: https://nuxt.com/raw/blog/v3-10.md

# Nuxt 3.10

> Nuxt 3.10 is out - packed with features and fixes. Here are a few highlights.

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](https://roe.dev/blog/shared-data-nuxt-generate)).

With [#24894](https://github.com/nuxt/nuxt/pull/24894), we are now able to do this automatically for you when prerendering your site. Your [`useAsyncData`](/docs/api/composables/use-async-data) and [`useFetch`](/docs/api/composables/use-fetch) calls will be deduplicated and cached between renders of your site.

```ts [nuxt.config.ts]
export defineNuxtConfig({
  experimental: {
    sharedPrerenderData: true
  }
})
```

<important>

It is particularly important to make sure that any unique key of your data is always resolvable to the same data. For example, if you are using `useAsyncData` to fetch data related to a particular page, you should provide a key that uniquely matches that data. (`useFetch` should do this automatically.)

</important>

<read-more to="/docs/guide/going-further/experimental-features#sharedprerenderdata">



</read-more>

### 🆔 SSR-safe accessible unique ID creation

We now ship a `useId` composable for generating SSR-safe unique IDs ([#23368](https://github.com/nuxt/nuxt/pull/23368)). This allows creating more accessible interfaces in your app. For example:

```vue [components/MyForm.vue]
<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](https://github.com/nuxt/nuxt/pull/24922)). The new `pages:routerOptions` hook allows module authors to do things like add custom `scrollBehavior` or add runtime augmenting of routes.

<read-more to="/docs/guide/going-further/custom-routing#router-options">



</read-more>

### <icon name="i-vscode-icons-file-type-node"></icon> Client-side Node.js support

We now support (experimentally) polyfilling key Node.js built-ins ([#25028](https://github.com/nuxt/nuxt/pull/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.

```ts [some-file.ts]
import { Buffer } from 'node:buffer'
import process from 'node:process'
```

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

```ts [plugins/node.client.ts]
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](https://developer.mozilla.org/en-US/docs/Web/API/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](https://github.com/nuxt/nuxt/pull/25198)).

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

<read-more to="/docs/api/utils/refresh-cookie">



</read-more>

### 🏥 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](https://github.com/nuxt/nuxt/pull/25259)).
- We warn (in development only) if data fetch composables are used wrongly ([#25071](https://github.com/nuxt/nuxt/pull/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](https://github.com/nuxt/nuxt/pull/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](https://github.com/nuxt/nuxt/pull/25264)).

You need to have experimental view transitions support enabled first:

```ts [nuxt.config.ts]
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:

```vue [pages/index.vue]
<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](https://github.com/nuxt/nuxt/pull/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](https://github.com/nuxt/nuxt/pull/25210)).

```ts [nuxt.config.ts]
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](https://github.com/nuxt/nuxt/pull/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](https://github.com/vuejs/tsconfig/blob/mainz/tsconfig.json#L24-L26) and [by Vite](https://vitejs.dev/guide/performance.html#reduce-resolve-operations), 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.

```ts [nuxt.config.ts]
export default defineNuxtConfig({
  future: {
    typescriptBundlerResolution: false
  }
})
```

## ✅ Upgrading

As usual, our recommendation for upgrading is to run:

```sh
npx 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

<read-more to="https://github.com/nuxt/nuxt/releases/tag/v3.10.0" icon="i-simple-icons-github" target="_blank">

Read the full release notes of Nuxt `v3.10.0`.

</read-more>

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 ✨**