@nuxt/docs-nightly 5.0.0-29758166.c429b54c → 5.0.0-29758188.0ff9da9b

package/1.getting-started/18.upgrade.md

@@ -342,6 +342,27 @@ In server routes, the error class is now `HTTPError` (replacing `createError` fr
 In the Vue part of your app (the `app/` directory), Nuxt's `createError` composable continues to work and is the recommended way to throw errors.
 ::
 
+#### `createError` No Longer Returns an `HTTPError` Instance
+
+`NuxtError` is now its own class rather than a subclass of h3's `HTTPError`, so `instanceof HTTPError` no longer matches an error created with Nuxt's `createError`. Everything else is unchanged: the error keeps the same properties, serialises the same way, and is still mapped to the right HTTP response during SSR.
+
+If you narrow errors by class, use one of the predicates instead:
+
+```diff
+- if (error instanceof HTTPError) {
++ if (HTTPError.isError(error)) {
+    // handles both `new HTTPError()` and Nuxt's `createError()`
+  }
+```
+
+```diff
++ import { isNuxtError } from '#app'
++
++ if (isNuxtError(error)) {
++   // narrows to errors created with Nuxt's `createError`
++ }
+```
+
 #### Server Event API Changes (h3 v2)
 
 The `H3Event` object now uses Web standard APIs:
@@ -437,6 +458,49 @@ If you previously set `experimental.externalVue` explicitly, you should now remo
 If you use `vue.runtimeCompiler: true`, the real compiler packages are still included as before.
 ::
 
+### `experimental.parseErrorData` Is No Longer Configurable
+
+🚦 **Impact Level**: Minimal
+
+#### What Changed
+
+The `experimental.parseErrorData` option is deprecated, and on Nuxt 5 it is forced on. Setting it to `false` logs a warning and is otherwise ignored, so `error.data` on the error page is always the value you passed to `createError`.
+
+On `compatibilityVersion: 4` the option still works and `false` still gives you a stringified `error.data`, so the behaviour only changes when you opt in to Nuxt 5.
+
+#### Reasons for Change
+
+When Nuxt renders an error page it fetches `/__nuxt_error` internally, passing the error along with the request. That used to spread the error across one query parameter per field, and because query values are always strings, `error.data` arrived as a string and had to be parsed back. `parseErrorData` existed to opt out of that parsing.
+
+The error is now sent as a single JSON-encoded parameter, so `error.data` keeps its original shape and is never stringified. Values also keep their types, so `status` is a number and booleans are booleans rather than the strings `'true'` and `'false'`. With nothing stringifying `error.data`, the option only survives to re-stringify it for apps that still expect a string.
+
+#### Migration Steps
+
+Remove the option:
+
+```diff
+  export default defineNuxtConfig({
+    experimental: {
+-     parseErrorData: false,
+    },
+  })
+```
+
+If you set it to `false` in order to keep parsing `error.data` yourself, drop that parsing too, as `error.data` now keeps whatever value you passed to `createError`:
+
+```diff
+  <script setup lang="ts">
+  import type { NuxtError } from '#app'
+
+  const props = defineProps({
+    error: Object as () => NuxtError
+  })
+
+- const data = JSON.parse(props.error.data)
++ const data = props.error.data
+  </script>
+```
+
 ### `@vitejs/plugin-vue-jsx` Is Now Optional
 
 🚦 **Impact Level**: Minimal

package/3.guide/6.going-further/1.experimental-features.md

@@ -192,12 +192,19 @@ export default defineNuxtConfig({
 
 ## parseErrorData
 
+::warning
+This option is deprecated and will be removed. With `compatibilityVersion: 5` it is forced on and setting it is ignored.
+::
+
 Whether to parse `error.data` when rendering a server error page.
 
-This flag is enabled by default, but you can disable this feature:
+It existed because the error was previously passed to the error page as individual query parameters, which stringified `error.data` and meant it had to be parsed back. Setting it to `false` opted out of that parsing and left you with the string.
+
+The error is now JSON-encoded as a whole, so `error.data` arrives with its original shape and is never stringified. On `compatibilityVersion: 4`, setting this to `false` stringifies it again so existing error pages that call `JSON.parse(error.data)` keep working:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
+  future: { compatibilityVersion: 4 },
   experimental: {
     parseErrorData: false,
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nuxt/docs-nightly",
-  "version": "5.0.0-29758166.c429b54c",
+  "version": "5.0.0-29758188.0ff9da9b",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/nuxt/nuxt.git",