Installation

npm install kasookoo-sdk

Installing also runs a postinstall step that copies the SDK's service worker into your app's public/static folder — required for push notifications, since browser push cannot mint a device token without it. It's copied as-is, already containing Kasookoo's Firebase config, and must end up served from your site root as /firebase-messaging-sw.js.

The postinstall step looks for a public/, static/ or www/ folder (or static/ specifically for SvelteKit) and copies into whichever it finds. If your project doesn't use one of those, or if your package manager has postinstall scripts disabled (e.g. --ignore-scripts, pnpm's default), run it yourself with an explicit output directory:

npx kasookoo-sdk --out path/to/public

If the file is ever missing or out of date, the SDK logs a console warning at runtime pointing back at this command.

Already running your own Firebase project in this app? Keep reading below before you install — copying Kasookoo's worker file over your own (or vice versa) will break one of them.

Push notifications with your own Firebase project

The SDK ships its own Firebase project — signaling pushes (incoming calls, messages) come from it, and it's embedded so you don't configure anything to receive them. The single-file setup above is all you need unless your app already runs its own Firebase project with its own service worker.

Why a rename alone doesn't work

Two service worker files can't both live at /firebase-messaging-sw.js — copying Kasookoo's file over your own (or vice versa) silently overwrites one of them and breaks its push notifications.

Renaming the file isn't enough by itself, either: a service worker's default registration scope is the directory it's served from. A renamed copy still sitting at your site root (e.g. /kasookoo-messaging-sw.js) still defaults to scope / — the same scope your own worker already occupies. Only one script can control a given (origin, scope) pair; registering a second one at the same scope replaces the first rather than letting the two run side by side.

The fix: a different filename and a different scope

npx kasookoo-sdk --out path/to/public --filename kasookoo-messaging-sw.js

const kasookoo = await KasookooClient.init({
    publishableKey: "pk_live_...",
    subject: "[email protected]",
    serviceWorkerPath: "/kasookoo-messaging-sw.js",
    serviceWorkerScope: "/kasookoo-push/",
})

The SDK registers this worker itself (rather than relying on Firebase's implicit default lookup) and hands that exact registration to Firebase when minting the device token — so it never touches, and is never replaced by, your own app's firebase-messaging-sw.js at the default scope. Your app's own Firebase setup needs no changes.

Both options default to the plain single-file setup if you don't have a Firebase project of your own to worry about — nothing here is required reading otherwise.