partykit

Patch Changes

• #568 a6bfedc Thanks @threepointone! - partysocket: remove room name validation

Patch Changes

• #563 0a92715 Thanks @threepointone! - revert sigil fix

Patch Changes

• #561 70dbd60 Thanks @threepointone! - fix: set this.worker sigil only after onStart has finished

Patch Changes

• #558 79dfe8f Thanks @threepointone! - partysocket: fix node usage

  When cloning websocket events in node, it looks like it misses the data field for messages. This patch adds it on to the cloned event.

• #560 34f5f9f Thanks @threepointone! - partysocket: fix node usage (error, closes, messages)

Patch Changes

• #555 f652575 Thanks @threepointone! - use --with-env to define .env vars as globals in the project

• #557 5a7fdcf Thanks @threepointone! - wrap .env values with quotes when inlining

Patch Changes

• #545 a5d4518 Thanks @threepointone! - 🎈 party.io: A socket.io backend for PartyKit

  This adds a new package, party.io, which is a fully compatible socket.io backend that runs on partykit. It also adds an example under /examples/scoket.io-chat. More details in the README. Pending docs update.

Patch Changes

• #542 ad4f8e5 Thanks @threepointone! - Update dependencies

Patch Changes

• #542 ad4f8e5 Thanks @threepointone! - Update dependencies

Patch Changes

• #542 ad4f8e5 Thanks @threepointone! - Update dependencies

Patch Changes

• #540 0e82337 Thanks @andrew-r-thomas! - adding room validation to partysocket

Patch Changes

• #529 1f5d5d9 Thanks @jevakallio! - Improvements to usePartySocket and useWebSocket hook reliability

Patch Changes

• #534 da3947e Thanks @andrew-r-thomas! - Assert that names of parties in partykit.json are lowercase

• #521 0e5a1b6 Thanks @threepointone! - update dependencies

  Of note, this now uses miniflare's new coloured logging, so we can start deprecating our weird inspector layer

• #512 059c133 Thanks @threepointone! - Update dependencies

• #530 12fc02a Thanks @jevakallio! - Allow passing request directly to stub.fetch

• #539 fd0e379 Thanks @andrew-r-thomas! - validating project name in config

Patch Changes

• #521 0e5a1b6 Thanks @threepointone! - update dependencies

  Of note, this now uses miniflare's new coloured logging, so we can start deprecating our weird inspector layer

Patch Changes

• #510 d9e8c74 Thanks @threepointone! - PartySocket.fetch: a fetch method with party options

  This adds PartySocket.fetch(), that constructs the URL with options similar to new PartySocket(). This makes it easier to fetch to parties without having to construct the URL yourself.

• #508 c64c58d Thanks @kentcdodds! - feat: add named usePartySocket export

• #499 6cc9437 Thanks @threepointone! - partysocket: add subpath support

  This patch lets you add path: string to new PartySocket({...}) and point to a subpath in a room. This is a client side analog to the recent subpath support we added to multiparty .fetch()/.socket()

Patch Changes

• #506 c57b51b Thanks @threepointone! - update deps

  Of note, this fixes partymix, our remix adapter

Patch Changes

• #509 77ce4b4 Thanks @jevakallio! - Parallellize asset uploads + fail fast

• #506 c57b51b Thanks @threepointone! - update deps

  Of note, this fixes partymix, our remix adapter

• #503 dbd7c3b Thanks @threepointone! - fix: get proper room id from /party/:id/*

  We had a bug when picking out the room name from /party/:id/*, it would pick the whole subpath instead. This fixes it.

• #504 80c147f Thanks @jevakallio! - partykit cli: fix session expiration for long-running deployments

Patch Changes

• #506 c57b51b Thanks @threepointone! - update deps

  Of note, this fixes partymix, our remix adapter

Patch Changes

• #494 24b33d8 Thanks @jevakallio! - y-partykit: Implement WebSocket chunking for y-partykit/provider

  Workers platform limits individual WebSocket message size to 1MB. There are legitimate situations when YPartyKitProvider sync messages can exceed 1MB.

  This is an experimental fix to batch messages into 1MB chunks.

• #483 08d54ea Thanks @jevakallio!

Improved y-partykit persistence

This release includes bugfixes and new options to y-partykit server persistence layer.

Background

By default, PartyKit maintains a copy of the Yjs document as long as at least one client is connected to the server. When all clients disconnect, the document state may be lost.

To persists the Yjs document state between sessions, you can use the built-in PartyKit storage by enabling the persist option.

This release fixes known performance and scaling issues with the existing persist: true option, and deprecates it in favour of two separate persistence strategies: snapshot, and history.

Persisting snapshots (recommended)

In snapshot mode, PartyKit stores the latest document state between sessions.

onConnect(connection, party, {
  persist: {
    mode: "snapshot",
  },
});

During a session, PartyKit accumulates individual updates and stores them as separate records. When an editing session ends due to last connection disconnecting, PartyKit merges all updates to a single snapshot.

The snapshot mode is optimal for most applications that do not need to support long-lived offline editing sessions.

Persisting update history (advanced)

In history mode, PartyKit stores the full edit history of the document.

This is useful when multiple clients are expected to be able to change the document while offline, and synchronise their changes later.

    onConnect(connection, party, {
      persist: {
        mode: "history",
      },
    });

For long-lived documents, the edit history could grow indefinitely, eventually reaching the practical limits of a single PartyKit server instance. To prevent unbounded growth, PartyKit applies a 10MB maximum limit to the edit history.

You can customise these limits as follows:

onConnect(connection, party, {
      persist: {
        mode: "history",
        // Maximum size in bytes.
        // You can set this value to any number below 10MB (10_000_000 bytes).
        maxBytes: 10_000_000,

        // Maximum number of updates.
        // By default, there is no maximum, and history grows until maximum amount of bytes is reached.
        maxUpdates: 10_000,
      },
});

Once either limit is reached, the document is snapshotted, and history tracking is started again.

Deprecating persist: true

In previous versions, PartyKit only had one persistence mode:

onConnect(connection, party, { persist: true });

In this mode, PartyKit would store the full edit history of the Yjs document in the party storage. This worked well for short-lived documents, but would break for long-lived documents, as the document history size would grow until it would reach the practical limits of the runtime environment.

From this version onwards, persist: true will function identically to setting persist: { mode: "history" }, including respecting the maximum storage limits.

This option is still supported for backwards compatibility reasons, but will be removed in a future version of y-partykit.

Patch Changes

• #487 2e802f3 Thanks @threepointone! - don't mark react as a dependency for partysocket

  This dependency causes way too many issues, especially since react doesn't work with multiple versions. Let's see if removing it helps.

• #490 96df6d9 Thanks @threepointone! - partysocket: don't bundle react into the built assets

  tsup ignores pnly dependencies marked in package.json under dependencies/devDependencies. Since we don't have react in here, it was bundling it into partysocket/react, leading to multiple versions being loaded into the same space. This explicity excludes react from the bundle.

Patch Changes

• #496 fb62640 Thanks @threepointone! - update deps

• #489 6276a29 Thanks @threepointone! - partykit bin field should be an object

• #481 731fea7 Thanks @threepointone! - pass sub path/init during subparty .fetch()/.socket()

  This lets you pass a "sub" path to a sub party .fetch() or .socket() (and adds being able to pass a RequestInit to .socket()). This make it possible to do routing more cleanly inside sub parties, making them more versatile.