Version 2 of our JavaScript client libraries

Spatie released version 2 of all four JavaScript client libraries for its Flare error-tracking service, including @flareapp/js, @flareapp/react, @flareapp/vue, and @flareapp/vite. The update introduces a faster ingestion endpoint with automatic redaction of sensitive query parameters, full-featured error recovery in the React and Vue integrations, and a new sampleRate option for controlling error reporting volume. The release aims to provide developers with more robust error handling and debugging capabilities directly within their applications.

We just shipped new major versions of all four JavaScript packages: @flareapp/js https://github.com/spatie/flare-client-js/tree/main/packages/js , , https://github.com/spatie/flare-client-js/tree/main/packages/react @flareapp/react , and https://github.com/spatie/flare-client-js/tree/main/packages/vue @flareapp/vue . https://github.com/spatie/flare-client-js/tree/main/packages/vite @flareapp/vite The framework packages went from minimal error forwarders to full-featured integrations, the core client talks to a new ingestion endpoint, and the Vite plugin handles failure gracefully. What changed in the core client @flareapp/js now uses a new, faster ingestion endpoint with a different payload format. Sensitive query-string parameters like password , token , and secret are automatically redacted from URLs in your error reports. Browser context URL, viewport, cookies, user agent is collected on every report without any setup on your end. There's also a new sampleRate option, the default value is 1 record all errors . If you're dealing with high traffic and don't need every single error reported you can do the following: flare.light 'your-api-key' ; flare.configure { sampleRate: 0.5 } ; // report ~50% of errors React: from catch-and-forward to full error recovery In v1, FlareErrorBoundary did one thing: catch the error and forward it to Flare. When something broke, your users saw a blank screen. Or you had to implement your own error boundary using the JS client, making the use of the react client unnecessary. js // v1: catch and forward, nothing more import { FlareErrorBoundary } from '@flareapp/react'; <FlareErrorBoundary <App / </FlareErrorBoundary // Error happens - component tree disappears - white screen v2 turns the boundary into an error recovery component. You get fallback UI, a reset mechanism, and lifecycle hooks to control what gets reported: js import { FlareErrorBoundary } from '@flareapp/react'; <FlareErrorBoundary fallback={ { error, resetErrorBoundary } = <div <p Something went wrong: {error.message}</p <button onClick={resetErrorBoundary} Try again</button </div } resetKeys={ location.pathname } beforeEvaluate={ = { flare.addContext 'page', 'checkout' ; }} <App / </FlareErrorBoundary resetKeys mirrors the API from react-error-boundary https://github.com/bvaughn/react-error-boundary : when any value in the array changes a route navigation, a retry counter , the boundary resets automatically and your component tree re-renders. No manual wiring needed. The fallback prop accepts either a React node or a render function. The render function gives you the caught error , the parsed componentStack , and a resetErrorBoundary callback. For React 19 projects using createRoot , there's a new flareReactErrorHandler that plugs directly into the error callbacks: js import { flareReactErrorHandler } from '@flareapp/react'; const root = createRoot document.getElementById 'root' , { onCaughtError: flareReactErrorHandler , onUncaughtError: flareReactErrorHandler , } ; Component stacks are now parsed into structured frames with file, line, and column info, giving Flare the data it needs to show you a component tree in a JSON format for now . Vue: error boundaries, route context, and props capture v1 was a thin app.config.errorHandler wrapper: js // v1: set the error handler, nothing else import { flareVue } from '@flareapp/vue'; app.use flareVue ; v2 accepts options, captures Vue Router context automatically, and can forward warnings in development: js import { flareVue } from '@flareapp/vue'; app.use flareVue, { captureWarnings: true, attachProps: true, propsDenylist: /password|secret|token/i, beforeSubmit: { error, context } = { console.log Reporting: ${error.message} ; return context; }, } ; And like React, Vue gets its own FlareErrorBoundary component with a scoped fallback slot: js <script setup import { FlareErrorBoundary } from '@flareapp/vue'; </script <template <FlareErrorBoundary :reset-keys=" route.fullPath " <SomeComponent / <template fallback="{ error, componentHierarchy, resetErrorBoundary }" <p Something went wrong: {{ error.message }}</p <p Component trail: {{ componentHierarchy.join ' ' }}</p <button @click="resetErrorBoundary" Try again</button </template </FlareErrorBoundary </template The fallback slot exposes the error, the full component hierarchy as an array, parsed hierarchy frames with props if attachProps is enabled , and the reset callback. One breaking change: Vue 2 support is dropped. If you're still on Vue 2, pin @flareapp/vue@1 . Vite plugin @flareapp/vite now retries failed sourcemap uploads with exponential backoff. A single failed upload no longer aborts the rest. You can also skip uploads entirely by setting SKIP SOURCEMAPS=true , which is useful for CI jobs that don't need them. Upgrading Install the latest versions: React projects npm install @flareapp/js@latest @flareapp/react@latest @flareapp/vite@latest Vue projects npm install @flareapp/js@latest @flareapp/vue@latest @flareapp/vite@latest Most of the API surface stayed the same. light , configure , report , glow , addContext , addContextGroup , test all work like before. What did change: Two config keys were renamed. If you use configure with custom URLs or sourcemap versions, update the key names: -reportingUrl: 'https://...', +ingestUrl: 'https://...', -sourcemapVersion: 'abc123', +sourcemapVersionId: 'abc123', Deprecated property setters are gone. If you were setting hooks or stage via assignment, move them into configure : js -flare.beforeEvaluate = error = error; -flare.beforeSubmit = report = report; -flare.stage = 'production'; +flare.configure { beforeEvaluate: error = error, beforeSubmit: report = report, stage: 'production', +} ; reportMessage signature changed. The third parameter was exceptionClass an arbitrary string ; it's now level a MessageLevel like 'info' or 'warning' in the second position: -flare.reportMessage 'Something happened', { orderId: 42 }, 'Log' ; +flare.reportMessage 'Something happened', 'warning', { orderId: 42 } ; Report payload fields are now camelCase. If your beforeSubmit callback inspects the report object, the field names changed: | v1 | v2 | |---|---| report.exception class | report.exceptionClass | report.seen at | report.seenAtUnixNano | report.context | report.attributes | report.glows | report.events | report.stacktrace i .line number | report.stacktrace i .lineNumber | The full migration guide covers every breaking change: v1 to v2 migration guide https://github.com/spatie/flare-client-js/blob/main/docs/v1-to-v2-migration.md . The docs have been updated with full guides for each package: Back to overview https://flareapp.io/blog Continue reading Flare news · April 30, 2026 https://flareapp.io/blog/flare-livewire Flare ❤️ Livewire Flare has deep Livewire visibility: components nested in traces with full hierarchy, per-phase timing mount, hydrate, render, dehydrate , aggregated component views with bidirectional links, rich error context, and a lot more. Let us show you how Flare can assist in debugging your Livewire project. Ruben Deep Dives · April 22, 2026 https://flareapp.io/blog/integration-testing-our-laravel-package-with-a-real-server-and-queue Integration testing our Laravel package with a real server and queue When unit tests aren't enough. We started testing the Laravel Flare package against a real application in order to verify that our code works using orchestra workbench. Here's how we did it. Ruben Subscribe to Backtrace, our quarterly Flare newsletter No spam, just news & product updates