npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@supapower/worker

v0.1.0

Published

A more stable drop-in replacement for PGlite's built-in multi-tab worker, using a SharedWorker with automatic fallback

Readme

@supapower/worker

A more stable drop-in replacement for PGlite's built-in multi-tab worker: one SharedWorker hosts the PGlite database for every tab, so the database is never owned by a particular tab and never has to be handed over when one closes, with PGlite's own dedicated-worker setup as an automatic fallback for browsers without SharedWorker (or where it fails to start). Works with plain PGlite - Supapower is not required.

Status: Below 1.0.0. The public API may still change.

Installation

npm install @supapower/worker @electric-sql/pglite

@electric-sql/pglite is a peer dependency - install it alongside this package. The peer range is >=0.5.8 <0.6.0: this package depends on PGlite's internal worker handshake, which is only guaranteed to stay compatible within a minor version.

(of course, you can use the package manager of your choice, e.g. bun or pnpm)

Usage

1. Write the worker script

// ./pglite-worker.ts
import { worker } from '@supapower/worker/worker';
import { PGlite } from '@electric-sql/pglite';

worker({
  async init(options) {
    return await PGlite.create(options);
  },
});

worker() detects at runtime whether it is running as a SharedWorker or a dedicated Worker and speaks the right protocol for each - the same script works for both, so there is only ever one worker file to write.

2. Connect from the tab

// ./pglite.ts
import { createPGliteWorker } from '@supapower/worker';

export const pg = await createPGliteWorker(
  {
    shared: () =>
      new SharedWorker(new URL('./pglite-worker.ts', import.meta.url), { type: 'module' }),
    fallback: () => new Worker(new URL('./pglite-worker.ts', import.meta.url), { type: 'module' }),
  },
  { id: 'my-app' },
);

console.log('Transport:', pg.transport); // 'shared-worker' or 'worker'

id is required. It is the only value that makes both transports agree on one election lock and one broadcast channel - PGliteWorker's own default id is derived from its own import.meta.url, which differs between the shared and the fallback worker scripts and would otherwise let the two open the same dataDir as if they were unrelated databases. Pick one stable id per database your app opens.

The returned pg is a PGliteWorker - every method, extension and the live query API work exactly as documented there, and any code written against PGlite's own multi-tab worker keeps working unchanged. pg.transport reports which side actually won: 'shared-worker' when the SharedWorker started within sharedWorkerTimeout (10 seconds by default), 'worker' otherwise.

3. (Optional) Sync with Supapower

Nothing above needs Supapower - pg is a plain PGliteWorker and works with any PGlite extension. Apps that do use it wire it up the same way as with PGlite's own worker:

import { extensions } from '@supapower/vue'; // or `@supapower/react`, or plain `supapower`

export const pg = await createPGliteWorker(
  { shared: () => new SharedWorker(/* … */), fallback: () => new Worker(/* … */) },
  { id: 'my-app', extensions },
);

const sync = await pg.supapower.sync({ supabase, tables: ['todos'] });

extensions goes on this, the client side, call - not inside the worker's init() - the same rule as PGliteWorker.create itself, since createPGliteWorker strips extensions before forwarding the rest of the options to the worker.

What differs from PGlite's own multi-tab worker

  • One worker instance for every tab. PGlite's dedicated-worker transport elects one tab to host the database and hands it over when that tab closes. A SharedWorker is not owned by any tab, so there is nothing to hand over - it simply outlives every tab until the last one disconnects.
  • pg.isLeader is always false on the shared transport. There is only ever one SharedWorker instance per database, so there is nothing to elect a leader among. Code that reads isLeader to decide who does work needs a different signal on this transport - Supapower's own outgoing-sync leadership already handles this by electing on tab visibility instead, see Multi-tab behavior in its README.
  • Safari ignores the SharedWorker constructor's name option. Separate two databases by using a different worker script URL and a different id, not by name.

License

Apache-2.0