Four shared type families merge edits, while the server stays separate
Yjs exposes 4 shared type families: arrays, maps, text, and XML. They absorb concurrent edits and reach the same result. Each type can be observed like a local object, while document updates may arrive out of order or more than once. That is the useful abstraction: your editor code works with a document instead of resolving competing cursor positions by hand. Offline work can merge after a client reconnects.
The boundary is equally important. Yjs is network agnostic, so the core does not choose a server, database, identity system, or permission model. Release v13.6.33 is the latest stable GitHub release, while the current main branch identifies itself as a 14.0.0 release candidate. Adoption means choosing a mature merge engine plus an ecosystem of adapters instead of one prescribed collaboration stack.
A provider supplies the server and persistence Yjs leaves out
The README's 2-package quick start pairs Yjs with y-websocket, while its production guidance recommends a network provider plus a persistence provider. y-webrtc exchanges updates between peers, and y-indexeddb keeps browser state for faster local loading and offline work. Hosted and self-hosted alternatives add their own storage, authentication, webhooks, or operational model. This freedom is useful when collaboration must fit an existing product, but the architectural choice lands on your team.
The quick start installs yjs and y-websocket, then starts the sample WebSocket server on port 1234. No credential is required for the core library or that local example. A real deployment still needs an answer for who may join a document, where updates persist, how rooms are named, and what happens when a provider is unavailable. Those answers live outside this repository.
What happened when we ran it
We measured a 5-second install for commit c286557 in our sandbox. npm added 376 packages, and the installed tree occupied 96 MB. The supplied test command succeeded in 17 seconds. There was no build target named build, so we skipped that step instead of substituting another command. npm audit found 0 known vulnerabilities across the dependency tree.
The checkout itself was small: 75 files, about 23,917 lines of source, and 1.2 MB on disk. It included 3 CI workflow files and a tests directory, but no Dockerfile. The container had 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. These results verify installation and the repository's test path. They do not measure sync latency, document size, editor behavior, or performance under concurrent users.
Stable v13 releases and current issue work show active maintenance
GitHub recorded a push on September 29, 2026, and v13.6.33 was published six days earlier. That release fixed deep-observer event targeting and closed issue 768 through pull request 801. The repository also showed 22,859 stars and 138 open issues and pull requests. A new UndoManager bug report, issue 806, was opened on September 27, so the queue contains current user reports rather than only old residue.
Main is already on @y/y 14.0.0-rc.28 and requires Node 22 or newer, although the README's consumer command still installs yjs. That split deserves attention if you build from source, follow main, or maintain extensions against internal behavior. Most users should pin a published stable version and test their chosen editor binding and provider together rather than treating a passing core suite as proof of end-to-end compatibility.
Untrusted binary updates need limits while issue 687 is open
Yjs defines 2 binary update formats for document changes. Updates are commutative and idempotent, and state vectors let peers exchange only missing differences. The API can even merge or diff updates without loading a full document. Version 2 improves compression, but the README says it is not supported by every provider. Mixing formats or components therefore needs a compatibility check before rollout.
Open issue 687 reports malformed update buffers that can make merge or apply operations loop indefinitely or run out of memory. The report includes reproductions against Yjs 13.6.21 and remained open after an August 26, 2026 update. We did not reproduce that claim in our sandbox, and 0 npm audit findings do not settle it because an advisory scan is different from testing hostile input. Services accepting client updates should validate trust boundaries, isolate work, and enforce resource limits.
Editor bindings save integration work, but product behavior is still yours
Seven documented editor integrations include ProseMirror, Tiptap, Quill, CodeMirror, Monaco, Lexical, and Slate, with more listed in the README. Yjs also provides relative positions, snapshots, and an UndoManager, while providers can carry cursor awareness. Those pieces remove a large amount of low-level collaboration work. They do not decide how comments attach to changing text, which actions share an undo history, or how a user recovers from a rejected update.
Storage needs the same care. The README explains that text-oriented CRDTs grow as edits accumulate, then describes how Yjs merges adjacent structures, removes deleted content, and garbage-collects some tombstones. Setting doc.gc to false preserves information needed to restore old content, with a storage cost. Before committing, test the documents you actually keep, over the retention window you actually promise. Our 17-second suite says the core passed; your provider, editor, access rules, and history policy decide whether the product does.

