{"slug": "version-2-of-our-javascript-client-libraries", "title": "Version 2 of our JavaScript client libraries", "summary": "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.", "body_md": "We just shipped new major versions of all four JavaScript packages: [ @flareapp/js](https://github.com/spatie/flare-client-js/tree/main/packages/js),\n\n[,](https://github.com/spatie/flare-client-js/tree/main/packages/react)\n\n`@flareapp/react`\n\n[, and](https://github.com/spatie/flare-client-js/tree/main/packages/vue)\n\n`@flareapp/vue`\n\n[.](https://github.com/spatie/flare-client-js/tree/main/packages/vite)\n\n`@flareapp/vite`\n\nThe 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.\n\n### What changed in the core client\n\n`@flareapp/js`\n\nnow uses a new, faster ingestion endpoint with a different payload format. Sensitive query-string parameters like `password`\n\n, `token`\n\n, and `secret`\n\nare 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.\n\nThere's also a new `sampleRate`\n\noption, 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:\n\n```\nflare.light('your-api-key');\nflare.configure({ sampleRate: 0.5 }); // report ~50% of errors\n```\n\n### React: from catch-and-forward to full error recovery\n\nIn v1, `FlareErrorBoundary`\n\ndid 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.\n\n``` js\n// v1: catch and forward, nothing more\nimport { FlareErrorBoundary } from '@flareapp/react';\n\n<FlareErrorBoundary>\n    <App />\n</FlareErrorBoundary>\n// Error happens -> component tree disappears -> white screen\n```\n\nv2 turns the boundary into an error recovery component. You get fallback UI, a reset mechanism, and lifecycle hooks to control what gets reported:\n\n``` js\nimport { FlareErrorBoundary } from '@flareapp/react';\n\n<FlareErrorBoundary\n    fallback={({ error, resetErrorBoundary }) => (\n        <div>\n            <p>Something went wrong: {error.message}</p>\n            <button onClick={resetErrorBoundary}>Try again</button>\n        </div>\n    )}\n    resetKeys={[location.pathname]}\n    beforeEvaluate={() => {\n        flare.addContext('page', 'checkout');\n    }}\n>\n    <App />\n</FlareErrorBoundary>\n```\n\n`resetKeys`\n\nmirrors 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.\n\nThe `fallback`\n\nprop accepts either a React node or a render function. The render function gives you the caught `error`\n\n, the parsed `componentStack`\n\n, and a `resetErrorBoundary`\n\ncallback.\n\nFor React 19 projects using `createRoot`\n\n, there's a new `flareReactErrorHandler()`\n\nthat plugs directly into the error callbacks:\n\n``` js\nimport { flareReactErrorHandler } from '@flareapp/react';\n\nconst root = createRoot(document.getElementById('root'), {\n    onCaughtError: flareReactErrorHandler(),\n    onUncaughtError: flareReactErrorHandler(),\n});\n```\n\nComponent 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).\n\n### Vue: error boundaries, route context, and props capture\n\nv1 was a thin `app.config.errorHandler`\n\nwrapper:\n\n``` js\n// v1: set the error handler, nothing else\nimport { flareVue } from '@flareapp/vue';\napp.use(flareVue);\n```\n\nv2 accepts options, captures Vue Router context automatically, and can forward warnings in development:\n\n``` js\nimport { flareVue } from '@flareapp/vue';\n\napp.use(flareVue, {\n    captureWarnings: true,\n    attachProps: true,\n    propsDenylist: /password|secret|token/i,\n    beforeSubmit: ({ error, context }) => {\n        console.log(`Reporting: ${error.message}`);\n        return context;\n    },\n});\n```\n\nAnd like React, Vue gets its own `FlareErrorBoundary`\n\ncomponent with a scoped `#fallback`\n\nslot:\n\n``` js\n<script setup>\nimport { FlareErrorBoundary } from '@flareapp/vue';\n</script>\n\n<template>\n    <FlareErrorBoundary :reset-keys=\"[route.fullPath]\">\n        <SomeComponent />\n        <template #fallback=\"{ error, componentHierarchy, resetErrorBoundary }\">\n            <p>Something went wrong: {{ error.message }}</p>\n            <p>Component trail: {{ componentHierarchy.join(' > ') }}</p>\n            <button @click=\"resetErrorBoundary\">Try again</button>\n        </template>\n    </FlareErrorBoundary>\n</template>\n```\n\nThe fallback slot exposes the error, the full component hierarchy as an array, parsed hierarchy frames (with props if `attachProps`\n\nis enabled), and the reset callback.\n\nOne breaking change: Vue 2 support is dropped. If you're still on Vue 2, pin `@flareapp/vue@1`\n\n.\n\n### Vite plugin\n\n`@flareapp/vite`\n\nnow 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`\n\n, which is useful for CI jobs that don't need them.\n\n### Upgrading\n\nInstall the latest versions:\n\n```\n# React projects\nnpm install @flareapp/js@latest @flareapp/react@latest @flareapp/vite@latest\n\n# Vue projects\nnpm install @flareapp/js@latest @flareapp/vue@latest @flareapp/vite@latest\n```\n\nMost of the API surface stayed the same. `light()`\n\n, `configure()`\n\n, `report()`\n\n, `glow()`\n\n, `addContext()`\n\n, `addContextGroup()`\n\n, `test()`\n\nall work like before.\n\nWhat did change:\n\n**Two config keys were renamed.** If you use `configure()`\n\nwith custom URLs or sourcemap versions, update the key names:\n\n```\n-reportingUrl: 'https://...',\n+ingestUrl: 'https://...',\n-sourcemapVersion: 'abc123',\n+sourcemapVersionId: 'abc123',\n```\n\n**Deprecated property setters are gone.** If you were setting hooks or stage via assignment, move them into `configure()`\n\n:\n\n``` js\n-flare.beforeEvaluate = (error) => error;\n-flare.beforeSubmit = (report) => report;\n-flare.stage = 'production';\n+flare.configure({\n beforeEvaluate: (error) => error,\n beforeSubmit: (report) => report,\n stage: 'production',\n+});\n```\n\n** reportMessage signature changed.** The third parameter was\n\n`exceptionClass`\n\n(an arbitrary string); it's now `level`\n\n(a `MessageLevel`\n\nlike `'info'`\n\nor `'warning'`\n\n) in the second position:\n\n```\n-flare.reportMessage('Something happened', { orderId: 42 }, 'Log');\n+flare.reportMessage('Something happened', 'warning', { orderId: 42 });\n```\n\n**Report payload fields are now camelCase.** If your `beforeSubmit`\n\ncallback inspects the report object, the field names changed:\n\n| v1 | v2 |\n|---|---|\n`report.exception_class` |\n`report.exceptionClass` |\n`report.seen_at` |\n`report.seenAtUnixNano` |\n`report.context` |\n`report.attributes` |\n`report.glows` |\n`report.events` |\n`report.stacktrace[i].line_number` |\n`report.stacktrace[i].lineNumber` |\n\nThe 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).\n\nThe docs have been updated with full guides for each package:\n\n[Back to overview](https://flareapp.io/blog)\n\n## Continue reading\n\n[\nFlare news\n·\nApril 30, 2026\n](https://flareapp.io/blog/flare-livewire)\n\n## Flare ❤️ Livewire\n\nFlare 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.\n\nRuben\n\n[\nDeep Dives\n·\nApril 22, 2026\n](https://flareapp.io/blog/integration-testing-our-laravel-package-with-a-real-server-and-queue)\n\n## Integration testing our Laravel package with a real server and queue\n\nWhen 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.\n\nRuben\n\n## Subscribe to Backtrace, our quarterly Flare newsletter\n\nNo spam, just news & product updates", "url": "https://wpnews.pro/news/version-2-of-our-javascript-client-libraries", "canonical_source": "https://flareapp.io/blog/version-2-of-our-javascript-client-libraries", "published_at": "2026-05-12 09:00:06+00:00", "updated_at": "2026-05-26 09:15:45.638027+00:00", "lang": "en", "topics": ["ai-tools", "ai-products"], "entities": ["Flare", "Spatie", "@flareapp/js", "@flareapp/react", "@flareapp/vue", "@flareapp/vite", "FlareErrorBoundary"], "alternates": {"html": "https://wpnews.pro/news/version-2-of-our-javascript-client-libraries", "markdown": "https://wpnews.pro/news/version-2-of-our-javascript-client-libraries.md", "text": "https://wpnews.pro/news/version-2-of-our-javascript-client-libraries.txt", "jsonld": "https://wpnews.pro/news/version-2-of-our-javascript-client-libraries.jsonld"}}