Installation

The @flareapp/js package is the core Flare client for JavaScript. It catches unhandled errors and sends them to Flare.

If you're using React or Vue, see the dedicated installation guides:

Looking for the docs for V1 of the JavaScript SDK? Find them here.

Installing the Flare client

You can install the Flare client by running one of the following commands:

npm install @flareapp/js
# or
yarn add @flareapp/js
# or
pnpm add @flareapp/js

Next, you need to initialize the Flare client as early in your application as possible. Typically this would be in your app.js or index.js file.

import { flare } from "@flareapp/js";

// Only enable Flare in production, we don't want to waste your quota while you're developing:
if (process.env.NODE_ENV === 'production') {
    flare.light('PROJECT PUBLIC KEY');
}

// When using Vite, use import.meta.env.PROD instead:
if (import.meta.env.PROD) {
    flare.light('PROJECT PUBLIC KEY');
}

Please make sure that you're using your projects public key. You can find it on the project settings page, in one of the JavaScript installation sections.

If you're using the sourcemap plugin, you don't need to specify a project public key here. The sourcemap plugin will automatically hook up the flare.light() call to your project. You can read more about this in the sourcemap plugin documentation.

The Flare client is automatically available as window.flare in the browser, so you can interact with it from the console. To verify that the client was installed correctly and will report your frontend errors, build your code and run flare.test() in your browser console. This will send a real test error to Flare that will show up on your project's dashboard.

If something goes wrong during the installation, you can enable debug mode on the client by passing true as the second parameter in your flare.light command flare.light('key', true), or by calling flare.configure({ debug: true }).

Configuration

You can customize the Flare client using flare.configure(). Call it after flare.light():

import { flare } from '@flareapp/js';

flare.light('YOUR PROJECT PUBLIC KEY');

flare.configure({
    stage: 'production',
    maxGlowsPerReport: 50,
});

Available options

Option	Default	Description
`stage`	`''`	Environment identifier (e.g. `'production'`, `'staging'`).
`version`	`''`	Application version string (e.g. `'2.1.0'`). Sent as `service.version` in reports.
`maxGlowsPerReport`	`30`	Maximum number of glows (breadcrumbs) attached to each report.
`ingestUrl`	`https://ingress.flareapp.io/v1/errors`	Custom endpoint for error reports.
`reportBrowserExtensionErrors`	`false`	Whether to report errors caused by browser extensions. See reporting errors.
`debug`	`false`	Enable debug logging in the browser console.
`urlDenylist`	`DEFAULT_URL_DENYLIST`	A `RegExp` tested against query-string parameter names. Matching values are redacted from the `url.full` attribute and other URL-derived fields. Custom patterns are merged with the built-in denylist by default.
`replaceDefaultUrlDenylist`	`false`	When `true`, `urlDenylist` replaces the built-in denylist instead of extending it.
`sampleRate`	`1`	Number between `0` and `1` controlling what fraction of errors are reported. `0.5` means roughly 50% of errors are sent to Flare. Applies to `report()`, `reportMessage()`, and unhandled rejections.
`beforeEvaluate`		Hook called before an error is processed. Can be async. See client hooks.
`beforeSubmit`		Hook called before a report is sent. Can be async. See client hooks.

Customizing the URL denylist

The default urlDenylist redacts query-string values for the following sensitive parameter names: password, passwd, pwd, token, secret, authorization, auth, bearer, oauth, credentials, cookie, api_key, private_key, session, csrf, xsrf, pin, ssn, card_number, and cvv. Path and hash segments are left untouched.

A custom urlDenylist is merged with the built-in denylist by default, so you won't accidentally lose redaction for sensitive terms like password or token:

flare.configure({
    urlDenylist: /myCustomParam|internalId/i,
});

If the built-in denylist matches too aggressively for your use case, you can replace it entirely:

flare.configure({
    urlDenylist: /onlyThisParam/i,
    replaceDefaultUrlDenylist: true,
});

Next steps

If your application is a vanilla JavaScript application without a build process, you're all set! Keep reading if you're using a build process.

If your application uses a build process (using Webpack, Vite, …), your front-end code for production won't look like the original code anymore. This causes the code snippets attached to error reports to be malformed as well. You can use the Vite or Webpack plugin to circumvent this issue by uploading a sourcemap to Flare. Read more about resolving bundle code here.

Important notes

If flare.light() hasn't been called (e.g. in development when using the production guard), calls to flare.report() and flare.reportMessage() are silently ignored — no errors are thrown, no reports are queued. Enable debug: true via flare.configure({ debug: true }) to see console warnings when this happens.

Errors in a development environment might not always be reported, this is normal. If you want to be sure the Flare client is set up correctly, try it out in a production build on your machine.

Flare Client PHP V1 Resolving bundled code

On this page
Installing the Flare client
Configuration
Next steps
Important notes