I Shipped...

There was a tricky bug where a row created by a backend server would sometimes get permanently deleted on both the server and the client. The root cause was that when the server sends a row to a client without its full history, and the client later edits it, the server rejects the edit because it looks like the client is trying to create a new row without permission — and that rejection would flip an already-accepted row into a deleted state. I fixed the logic so that owner updates no longer trigger this incorrect hard-delete path.

I wired up type-checking for all the code examples embedded in Jazz's documentation — TypeScript, Svelte, and Vue variants. Before this, a snippet could have a type error and nobody would notice until a user tried to copy it. Now a broken snippet fails the build, so the docs always reflect working code.

I added a full end-to-end testing harness for Jazz's starter templates — the scaffolded projects a new user creates with create-jazz. The CI now actually builds each starter and runs Playwright browser tests against it before any release goes out, so a broken starter template can no longer silently ship to users.

The Jazz server was logging its full inspector URL at startup, which had the admin secret embedded directly in the link — meaning anyone with access to the logs could see the credential. I removed the secret from the logged URL and added a warning that fires when the server starts without production auth settings configured, so developers aren't silently running in an open state.

When a row has a very long chain of ancestors — around 300 levels deep — the code that forwards rows was calling itself recursively, eventually running out of call-stack space and crashing. I replaced the recursive approach with an iterative post-order walk, so deeply nested row histories no longer cause a stack overflow.

When the permission header for a piece of data arrived before the data itself, Jazz was incorrectly rejecting local writes. I removed a redundant authorization call so that Jazz waits until the full data bundle is received before enforcing permissions, eliminating a race condition that caused intermittent test failures in CI.

When a Svelte component imported a TypeScript file from outside the configured source root, the emitDts tool would create .d.ts type declaration files in the wrong place — sometimes nesting them deep in the source tree with doubled absolute paths. I fixed the file-writing hook to skip any declarations that fall outside the intended output directory and to only prepend relative path prefixes when the filename is already relative.

I added two defences to the Jazz sync server to prevent a type of denial-of-service attack called a "reconnect storm". First, I capped the number of simultaneous WebSocket connections allowed per client at 4, automatically dropping the oldest connection when the limit is hit and sending a "RateLimited" error code. Second, I added a 10-second timeout for connections that start their handshake but never finish, so idle half-open connections can't pile up indefinitely.

I found that the WebSocket handshake frame (the first message when a new connection opens) was being decompressed before we'd checked who was connecting. A malicious actor could send a tiny compressed frame that claimed to expand to gigabytes, crashing the server by running out of memory. I added a check that rejects any handshake frame claiming to be larger than 1 MB — since a real handshake is only a few kilobytes of data, anything bigger is suspicious.

When using jazz with Next.js, our withJazz helper was mistakenly telling Next.js to load jazz-tools as a separate server-side module instead of bundling it together with your app. This caused two separate copies of React to be loaded at the same time — one for the server-rendered pages, one for the client components — which crashes Next.js during pre-rendering. I fixed it by only excluding jazz-napi (the native binary) from bundling, so jazz-tools gets bundled normally with your app and there's just one React instance throughout.

I wrote docs for several previously-undocumented Jazz features: a CLI command for inspecting local schema hashes, guidance on what values to use in JWT sub claims (and why changing them later causes problems), how permission columns like $canRead work within nested queries, and two performance optimizations — .indexOnly() for leaner index lookups and .merge("counter") for summing concurrent integer edits without conflicts.

I added an interactive diagram to the Jazz documentation that lets you pick a durability tier — local, edge, or global — and watch how a data write propagates across a network of devices. This makes it easier to understand how Jazz handles consistency at different levels and what happens when a device is offline, without having to read through dense text explanations.

I replaced the Mermaid diagram library in the Jazz docs with a custom-built engine using <Graph> and <Sequence> components. Mermaid wasn't great for interactive, mobile-friendly diagrams — theming and layout control were too limited. The new engine handles desktop and mobile layouts in a single definition and supports animations. I also migrated the four existing diagrams and added 35 unit tests covering the geometry and layout logic.

I fixed a crash in the Jazz MCP server that happened on Node.js versions older than 22. The crash was caused by the text-search fallback accidentally importing node:sqlite — a database built-in that doesn't exist in older Node versions — before it even had a chance to activate. I extracted the SQLite-free parsing helpers into a new standalone file so the fallback module's dependency chain never touches the database code.

Jazz already had a React hook for LocalFirstAuth — a way to handle user login in local-first apps (apps that work offline and sync data in the background). I added matching reactive integrations for Svelte and Vue, so developers using those frameworks can use LocalFirstAuth without having to wire up their own reactivity. I also fixed a crash that occurred when the module was imported on the server side, and made sign-out properly propagate across all open tabs.

The Jazz starter templates had a lot of repetitive boilerplate for setting up authentication. I updated the SvelteKit, React, and Next.js starters to use the new LocalFirstAuth reactive class and framework-specific hooks, which means cleaner code and auth state that automatically rebuilds when something changes — no manual page reload needed.

Node.js 20 reached end-of-life, meaning it no longer receives security updates. I bumped the minimum required Node.js version to 22.12 and took the opportunity to clean up backwards-compatibility workarounds scattered across 19 files that only existed to support older Node versions.

I added a new example app showing how to build a local-first todo list using Vue 3 and Jazz. It mirrors the existing React, Svelte, and TypeScript examples, so Vue developers now have a reference starting point too. The example also includes browser-based integration tests using Vitest.

When you install Jazz using pnpm, it creates a symlink (a shortcut) pointing to the actual CLI program. The CLI checks whether it's the entry point by comparing file paths, but the symlinked path and the real path are different strings, so it thought it wasn't the entry point and quietly exited without doing anything — making schema pushes and migrations appear to succeed while actually no-oping. I fixed it by resolving both paths to their real locations before comparing them, so the CLI now dispatches correctly whether called directly or through pnpm's symlinks.

I replaced a static diagram on the "how sync works" docs page with an animated SVG that shows how writes flow between global sync servers, edge servers, and local clients in real time. To keep things readable, I made each writer get a randomly generated color that's always different enough from its previous color. I also refactored the diagram building blocks into a shared module so future diagrams can reuse the same code.