SvelteKit

@sentriq/sveltekit is a thin re-export of @sentriq/svelte — it initializes no second Browser SDK client and reimplements no state. Unlike @sentriq/nuxt (which wraps a real Nuxt module system — auto-imports, runtimeConfig, a runtime plugin registered against Nuxt's app instance), SvelteKit has no equivalent module/ plugin system for a library to hook into: every SvelteKit app owns its root +layout.svelte directly, so that is exactly where integration happens.

Install

npm install @sentriq/sveltekit

Root layout integration

<!-- src/routes/+layout.svelte -->
<script>
  import { createSentriq } from '@sentriq/sveltekit';
  import { PUBLIC_SENTRIQ_PUBLIC_KEY } from '$env/static/public';

  let { children } = $props();

  createSentriq({ publicKey: PUBLIC_SENTRIQ_PUBLIC_KEY });
</script>

{@render children()}

Any descendant route or component then calls getSentriq(), exactly as documented on the Svelte SDK page — there is no SvelteKit-specific hook API beyond this.

Public / private env boundary

Only a public Sentriq key may ever reach browser code. Read it via SvelteKit's own $env/static/public (variable names must start with PUBLIC_ — SvelteKit enforces this at build time, refusing to bundle anything else into client code) — never $env/static/private or a bare process.env read. Never pass a secret key (sec_...), a database credential, an SMTP password, or a webhook secret through this path — none of those belong in a Sentriq browser integration at all, on any framework.

Server-side rendering

The +layout.svelte above runs on both the server (per request) and the client — createSentriq() never touches window/document/navigator during the server pass, so the server- rendered HTML always reflects status: 'idle'. Do not call createSentriq() from hooks.server.ts, +layout.server.ts, or any +page.server.ts — those run in a context with no browser runtime at all and are not where this integration belongs.

Hydration

Loading a server-rendered page in a real browser transitions cleanly from the server's idle state to a hydrated ready state, with zero hydration mismatches — verified against a real @sveltejs/adapter-node production build and a real browser load.

Navigation

Client-side navigation between routes (SvelteKit's default, no full page reload) does not create a second Sentriq client or reset status — the root +layout.svelte that called createSentriq() stays mounted across route changes, so its Svelte context (and the client instance it holds) is naturally preserved. @sentriq/browser has no automatic pageview tracking to preserve, so this integration adds no automatic SvelteKit route-tracking either — call sentriq.track('page_view') yourself from an afterNavigate() callback if you want that behavior; doing so automatically here would risk double-firing events on the initial load.

Development / HMR

Editing a route component during vite dev hot- reloads only that component — the root layout (and therefore the Sentriq client it created) is not remounted, so status/ready and the underlying client instance survive HMR unchanged. Verified directly: two consecutive HMR edits to a route component, with a real event sent between them, both against the same, already-ready client.

Consent

Not applicable — see the Svelte SDK page.

Version compatibility

SvelteKit ^2.0.0 (peer range) with Svelte ^5.0.0; SvelteKit 2.63.x tested this phase, built for production with @sveltejs/adapter-node.