@omniaura/solid-pulse weekly downloads statistics

@omniaura/solid-pulse

Flash what actually updates in a SolidJS app — and give agents the same controls as humans.

solid-pulse is dev-only instrumentation for Solid. It watches the reactive graph through Solid's official dev hooks, the DOM through a MutationObserver, and the network through fetch/WebSocket/EventSource, and turns what it sees into precisely named events:

| Event | Meaning |

| solid.flush | a reactive update completed: *n* computations re-ran, by kind (memo/computed/effect/render) and by owning component | | solid.computation | one computation re-ran (only with verboseComputations) | | solid.component.mount / .dispose / .remount | a component function ran / its owner was disposed / the same-named child was disposed and recreated within a flush (gapMs) | | solid.root | a reactive root was created (multiple roots are counted, not conflated) | | dom.mutation | the DOM actually changed (targets, attribute names, added/removed counts, attribution to the flush's component) | | dom.detach | a subtree left the document, recording the scrollTop of every recently-scrolled descendant and whether focus was inside | | dom.reattach | the same node instance came back: gapMs, scrollReset: before→after, focusLost, suspenseInChain, a stable selector | | focus.lost | the focused element vanished from the document | | net.fetch.start/end/error | fetch lifecycle; SSE responses detected by content-type and counted frame by frame; aborts flagged | | net.ws.open/message/close/error | WebSocket lifecycle with subprotocols, direction, counts, type field of JSON frames, close codes | | net.sse.* | EventSource lifecycle (and fetch-based SSE) | | query.observe | a Solid Query observer subscribed — role: "initiating" (first observer, its mount causes the fetch) or "sharing" (query already had observers) — attributed to the Solid component | | query.fetch.start/success/error | with trigger: observer-mount \| invalidation \| background-refetch \| initial | | query.invalidate, query.update, query.unobserve, query.added/removed, mutation.* | the rest of the cache lifecycle |

There is deliberately no "rerender" event: Solid never re-runs component bodies. If one ever did, you would see a pulse.note saying so.

Install

The plugin injects the runtime as the first module script (so Solid's dev hooks are installed before your first render), mounts the raw-DOM panel, mounts the bridge on the Vite dev server at /__pulse, and writes node_modules/.vite/solid-pulse.json so the CLI finds it.

Manual setup (no Vite, or custom options):

Solid Query adapter (optional)

Read-only: it subscribes to the QueryCache/MutationCache and never changes query behaviour. With the Vite plugin, point setupModule: "/src/pulse-setup.ts" at a module that export default (pulse) => { attachQueryClient(pulse, queryClient) } — it is evaluated before your app's entry module, so the very first observers are attributed.

Bounded capture

The live page buffer retains at most 2,000 events and a 4 MiB estimated payload budget (whichever fills first). Old events roll out; status shows evictions. Each event is snapshotted with an 8,192-character / 256-node / 8-level budget, marks truncation, and never retains application object graphs. These are diagnostic budgets, not a claim that the browser process heap is exactly 4 MiB.

Recordings stop at 20,000 events or 4 MiB estimated payload, whichever comes first, with a reported stop reason. Five recent recordings are retained (up to roughly 20 MiB of budgeted payload). Invalid or unlimited recording limits are rejected. The panel renders recent rows in batches at most 10 times per second, with no live log DOM work while closed, hidden, or on another tab. Intermediate display rows may be coalesced; the page buffer remains available via events.list/export.

The bridge has a 200-event pending queue, drains up to 200 events in batches of 20 per 50 ms tick, and pauses event sends when the socket has 512 KiB pending. Saturated queues keep the newest events; drop counts appear in the panel, bridge.status, mirror events/clients and live tail. The initial/reconnect replay is the latest 200 events, not the full page history; use events.list (the page command) or export for more. The server mirror also has a 4 MiB payload budget. Slow CLI live tails disconnect above 512 KiB of queued output and report an error instead of accumulating output or ending silently; reconnect and query recent history, noting sequence gaps. SSE diagnostics retain at most 64 KiB of an incomplete frame; app response bytes pass through unchanged.

The bridge drop counter reports pending-queue evictions and omitted replay entries, not unique end-to-end losses: reconnect replay can include previously delivered events, and disconnects can discard unsent socket data. Use event sequence gaps to identify missing history.

The Record tab separates recordings from the rolling live log. Start recording, reproduce the issue, optionally add marker notes, then stop and download that recording's JSON. While active, Download snapshot exports that recording so far without stopping it. Download live log is a separate, unfiltered export of the rolling buffer. Capture pause affects both the live log and the active recording; Resume capture does not start a new recording. Automatic stops show whether the event or size limit was reached. Recordings stay in page memory only (latest five); download before reloading. All actions use the same record.*, note, events.resume and export recording= commands as agents.

Human Status/bridge status controls and CLI status/bridge.status expose limits and counters; the Record tab and record.list expose recording stop reasons. Capturing every event is inherently work; these bounds prevent retained history and rendering queues from growing with session duration, not zero overhead.…

Description from the npm listing.