Framework integrations

Nuxt integration

Nuxt ships its own <NuxtErrorBoundary> (wrapping onErrorCaptured) and the error.vue page for whole-app errors. This package is complementary, not a replacement:

• <NuxtErrorBoundary> is a thin, single-purpose wrapper with an #error slot and no retry/reset/reporting story of its own — reach for <ErrorBoundary> from this package when you want resetKeys, maxRetries, retry counts, or a reporter attached at the component level.
• error.vue handles errors that reach the app root (including ones a component-level boundary chose not to isolate, or that happened before any boundary mounted). Keep it as your last line of defense; use <ErrorBoundary> for the parts of the tree that should degrade gracefully instead of taking down the page.
• Both rely on the same underlying onErrorCaptured mechanism, so the same catch/no-catch list applies either way.

The vue-error-boundary-kit/nuxt module

Add it to nuxt.config.ts for auto-registration — no manual imports needed in your app code:

export default defineNuxtConfig({
  modules: ['vue-error-boundary-kit/nuxt'],
})

This registers <ErrorBoundary> as a global component and auto-imports useErrorBoundary, useGlobalErrorCapture, and useNuxtErrorBoundary (below) — verified end-to-end against a real Nuxt 4.5.2 app built from the published package tarball, including that nuxt.config.ts's module-options typing actually catches a wrong-shaped option.

Module options (all optional, both default true):

export default defineNuxtConfig({
  modules: ['vue-error-boundary-kit/nuxt'],
  errorBoundaryKit: {
    component: true, // register <ErrorBoundary> globally
    autoImports: true, // auto-import the three composables above
  },
})

@nuxt/kit is only a peer dependency of this package (peerDependenciesMeta.optional), never bundled into your app — it's already part of any Nuxt install, so there's nothing extra to add. Tested against Nuxt 4.5.2; the module's declared compatibility: { nuxt: '>=3.0.0' } is reasoned from @nuxt/kit's own cross-major (2/3/4) design rather than independently re-verified against Nuxt 3.

useNuxtErrorBoundary()

useErrorBoundary(), plus Nuxt's own vue:error and app:error hooks wired in — i.e. it also catches what escapes every <ErrorBoundary> in your tree (a render/setup error that reached the app root uncaught) and Nuxt's own showError()/createError() fatal-error flow, neither of which a component-level boundary ever sees. Both hooks run isomorphically, so this covers SSR and the client alike. Typically called once, e.g. in app.vue:

<!-- app.vue -->
<script setup lang="ts">
const { error } = useNuxtErrorBoundary({ reporter: sentryReporter })
</script>

<template>
  <ErrorBoundary :reporter="sentryReporter">
    <NuxtPage />
  </ErrorBoundary>
</template>

For errors you want the framework's own error.vue to handle (e.g. 404s from createError()), don't wrap them in a local boundary — let them propagate.

vue-router integration

vue-error-boundary-kit/router — useRouterErrorBoundary(), the vue-router-only equivalent of useNuxtErrorBoundary(). router.onError() is vue-router's own catch-all: it fires for errors thrown in navigation guards, errors passed to next(), and errors raised while resolving an async route component (component: () => import(...)) — none of which happen inside a component's render/setup lifecycle, so onErrorCaptured/<ErrorBoundary> structurally never sees them.

import { useRouterErrorBoundary } from 'vue-error-boundary-kit/router'

<!-- App.vue -->
<script setup lang="ts">
const { error } = useRouterErrorBoundary({ reporter: sentryReporter })
</script>

Same options as useErrorBoundary() (onError, beforeReset, reporter, reportContext, internalErrorPrefix); unsubscribes from router.onError() automatically on scope dispose. vue-router is an optional peer dependency, never bundled unless you import this entry point. Verified against a real router.onError() — both a throwing navigation guard and a rejected async route component were confirmed to actually reach it, against vue-router@5.2.0; the declared peerDependencies range (^4.0.0 || ^5.0.0) is reasoned from onError's stable, long-standing signature rather than independently re-verified against 4.x.

TanStack Query integration

<ErrorBoundary>'s retry()/reset() only re-render the tree. A useQuery() that already failed doesn't care — it stays in its cached error state and, with throwOnError set, re-throws that same stale error on the very next render, before its query function ever runs again. @tanstack/react-query solves this with QueryErrorResetBoundary; @tanstack/vue-query has no equivalent primitive, so vue-error-boundary-kit/tanstack-query provides one:

import { useQueryErrorReset } from 'vue-error-boundary-kit/tanstack-query'

<script setup lang="ts">
const resetErroredQueries = useQueryErrorReset()
</script>

<template>
  <ErrorBoundary :before-reset="resetErroredQueries">
    <template #default>
      <UserProfile :id="userId" />
      <!-- uses useQuery({ ..., throwOnError: true }) -->
    </template>
    <template #fallback="{ error, retry }">
      <ErrorState :message="error.message" @retry="retry" />
    </template>
  </ErrorBoundary>
</template>

useQueryErrorReset(options?) returns a synchronous callback that resets every query currently in an error state (queryClient.resetQueries({ predicate: (query) => query.state.status === 'error' })) — wire it into beforeReset so it runs right before the boundary's own re-render, and the retried query actually refetches instead of instantly failing again. Options: queryClient (default: useQueryClient() from context), id (forwarded to useQueryClient() for multi-client setups), internalErrorPrefix. @tanstack/vue-query is an optional peer dependency — never imported unless you import this entry point.