Flare by Spatie
    • Error Tracking
    • Performance Monitoring
    • Logs
  • Pricing
  • Docs
  • Insights
  • Changelog
  • Back to Flare ⌘↵ Shortcut: Command or Control Enter
  • Sign in
  • Try Flare for free
  • Error Tracking
  • Performance Monitoring
  • Logs
  • Pricing
  • Docs
  • Insights
  • Changelog
    • Back to Flare ⌘↵ Shortcut: Command or Control Enter
    • Try Flare for free
    • Sign in
Flare Flare Laravel Laravel PHP PHP JavaScript JavaScript React React Vue Vue Svelte Svelte Protocol Protocol
  • General
  • Installation
  • Resolving bundled code
  • API reference
  • Electron
  • Configuration
  • Errors
  • Error boundary
  • Error handler
  • SvelteKit error handling
  • Reporting errors
  • Client hooks
  • Data Collection
  • Adding custom context
  • Adding glows

Configuration

This guide covers using @flareapp/svelte inside an Electron renderer. If you haven't set up the core Electron client yet, start with how the Electron client works.

Same model as the React integration: the API key lives in main, reports travel over IPC, and the renderer injects Electron's Flare instance into Svelte instead of letting it reach the @flareapp/js singleton.

Install

npm install @flareapp/electron @flareapp/svelte

@flareapp/js comes in transitively via @flareapp/electron, so don't import it in the renderer.

1. Main process: owns the key and the transport

// main.ts
import { app } from 'electron';
import { flare } from '@flareapp/electron/main';

app.whenReady().then(() => {
    flare.light('YOUR PROJECT KEY'); // key lives ONLY here
});

2. Preload: bridges the renderer to main

// preload.ts
import { exposeFlare } from '@flareapp/electron/preload';

exposeFlare(); // exposes window.__flare.report() via contextBridge

Point your BrowserWindow at this preload with contextIsolation: true (the default).

3. Svelte: report through the Electron instance

In the renderer, @flareapp/electron/renderer gives you a Flare instance that forwards every report to the main process over IPC. Hand that instance to Svelte through @flareapp/svelte/inject so Svelte reports travel the same path. Two imports make this work:

  • flare from @flareapp/electron/renderer is the IPC-forwarding instance (no API key, no direct network calls).
  • FlareErrorBoundary (and createFlareErrorHandler) from @flareapp/svelte/inject is a build that takes a flare instance instead of reaching for a global client.
<script lang="ts">
    import { FlareErrorBoundary } from '@flareapp/svelte/inject';
    import { flare } from '@flareapp/electron/renderer';
</script>

<FlareErrorBoundary {flare}>
    <App />
</FlareErrorBoundary>

Or the handler directly (e.g. in a SvelteKit-free Svelte app's error hook):

import { createFlareErrorHandler } from '@flareapp/svelte/inject';
import { flare } from '@flareapp/electron/renderer';

const handleError = createFlareErrorHandler({ flare });

If you import flare in several spots, re-export it from a small local module (e.g. renderer/flare.ts) and import it from there. That is optional sugar; the imports above work on their own.

Component tracking (optional)

If you use Flare's Svelte component tracking, point the preprocessor at the inject entry so the generated per-component imports stay root-free in the renderer:

// svelte.config.js (renderer build)
import { withFlareConfig } from '@flareapp/svelte/inject';

export default withFlareConfig(
    {
        /* your svelte config */
    },
    { importSource: '@flareapp/svelte/inject' },
);

Without importSource, the preprocessor emits import ... from '@flareapp/svelte', which pulls the web singleton (and its global side effects) into the renderer. Set it to @flareapp/svelte/inject for Electron renderer builds.

Why the two special imports

In a normal web app, @flareapp/svelte and @flareapp/js share one global Flare client: it holds your API key and posts reports straight to Flare. That is exactly what you want in a browser, and exactly what you do not want in an Electron renderer, where the key has to stay in the main process and reports have to go over IPC.

The /inject entry and the explicit flare instance are how you opt out of that web behavior:

  • Import the boundary and handler from @flareapp/svelte/inject, not @flareapp/svelte. The regular entry quietly falls back to the global web client. The /inject entry has no global to fall back to, so it can only report through the instance you give it. (Import the regular entry by accident and Flare logs a console warning, so you can catch the mistake.)
  • Don't import @flareapp/js anywhere in the renderer. It would start a second global error listener and try to send reports directly to Flare with no API key, bypassing the main process entirely. The component-tracking preprocessor above is the easy way to slip up here, which is why importSource matters.
  • Always pass the flare instance. Forget it and Svelte throws at handler creation or component setup, the moment your app boots, not later when an error happens, so the mistake is obvious right away instead of silently dropping reports.

Once wired, reports from the renderer carry sdk = @flareapp/electron and framework = Svelte. Your Svelte context (context.custom.svelte, the component hierarchy) gets included in the IPC call to the main process.

API reference Error boundary
  • On this page
  • Install
  • 1. Main process: owns the key and the transport
  • 2. Preload: bridges the renderer to main
  • 3. Svelte: report through the Electron instance
  • Component tracking (optional)
  • Why the two special imports

Catch errors and fix slowdowns with Flare, the full-stack application monitoring platform for Laravel, PHP & JavaScript.

  • Platform
  • Error Tracking
  • Performance Monitoring
  • Pricing
  • Support
  • Resources
  • Insights
  • Newsletter
  • Changelog
  • Documentation
  • Affiliate program
  • uptime status badge Service status
  • Terms of use
  • DPA
  • Privacy & cookie Policy
Made in by
Flare