partykit

#476 ad6be5b Thanks @threepointone! - await multiparties.socket()

This introduces a new method .socket() to the multiparties bag. Much like the .fetch() method() on the bag, this now uses an internal api to connect with a websocket to the party, instead of using a URL and connecting via the internet. Importantly, this also works from inside onFetch() handlers. This patch also deprecates the previous .connect() method.

#473 cf8cb27 Thanks @jevakallio! - Fix login on WebKit (Safari)

#472 a9b17f9 Thanks @jevakallio! - Allow preflight requests when Chrome Private Network Access is enabled

#470 cdceba8 Thanks @dev-badace! - added missing crypto from node_compat

#465 3048a9f Thanks @threepointone! - fix: .send and .broadcast can send ArrayBuffers

WebSocket messages can be string | ArrayBuffer | ArrayBufferView, this patch fixes the types to allow that. The implementation remains the same (and otherwise always worked).

#463 1efd862 Thanks @threepointone! - update deps

#466 e8a8da4 Thanks @jevakallio! - Make connection.setState accept null

#461 34eeb03 Thanks @dependabot! - Bump zod from 3.22.2 to 3.22.3

#458 4b3e0e2 Thanks @jevakallio! - Add new connection.state and connection.getState methods.

import type * as Party from "partykit/server";

// optional: you can provide typescript types for state for additional type safety
type Connection = Party.Connection<{ country: string }>;

class PartyServer {
  onConnect(connection: Connection, { request }) {
    // you can .setState to store information on connection
    connection.setState({ country: request.cf.country });
  }
  onMessage(message: string, connection: Connection) {
    // you can access .state to get information stored with .setState
    console.log(`${message} from user in ${connection.state?.country}`);
  }
}

#450 3fd5fc9 Thanks @threepointone! - y-partykit: export unstable_getYDoc

This is an escape hatch to get access to the Y.Doc instance, or initialize it if one doesn't exist yet.

import type * as Party from "partykit/server";
import {
  onConnect,
  unstable_getYDoc,
  type YPartyKitOptions,
} from "y-partykit";

// options must match when calling unstable_getYDoc and onConnect
const opts: YPartyKitOptions = { persist: true };

export default class YjsServer implements Party.Server {
  yjsOptions: YPartyKitOptions = { persist: true };
  constructor(public party: Party.Party) {}

  async onRequest() {
    const doc = await unstable_getYDoc(this.party, opts);
    return new Response(doc.getText("message")?.toJSON());
  }

  onConnect(conn: Party.Connection) {
    return onConnect(conn, this.party, opts);
  }
}

Caveats

This API is marked unstable, because it's likely to be superceded by a better API in the future.

Notably, the options argument provided to unstable_getYDoc should match the options provided to onConnect. We do currently not change the options when each change is made, so the first options passed are applied, and any further changes are ignored. We try to detect changed options, and show a warning if changes are detected.

#449 239aaef Thanks @threepointone! - y-partykit: update deps

#456 af8af51 Thanks @threepointone! - y-partykit: only import things we need

#452 cb57107 Thanks @threepointone! - y-partykit: remove ping-pong

We had a ping-pong loop with partykit to keep the object alive, but it's not necessary. This patch removes it.

#437 8848863 Thanks @jevakallio! - Ensure that user attachments don't clobber system attachments used by partykit

#454 d9b9076 Thanks @threepointone! - make node@18 the minimum version required to run partykit

#440 9a9fd8a Thanks @threepointone! - experimental: dev --unstable_outdir <path>

When we have errors in the code, we log the error, but it uses line numbers from the output worker, which aren't helpful. Particularly because we don't output the actual worker to disk anyway, so they can't figure out where the error is coming from. It's really bad for large codebases.

Figuring out debugging is a top level concern for us; we want to have sourcemaps, breakpoints, devtools - the works. But until we get there, we should help people find where errors are coming from.

This adds an experimental --unstable_outdir <path> to partykit dev that spits out the actual code that we run in the dev environment, so folks can inspect it. The output code also inlines filenames, so that should help as well. This should hold folks until we have a better debugging story.

#442 532a241 Thanks @jevakallio! - Fix compatibilityDate timezone issue, allow server to decide timezone if not provided

#436 645edd6 Thanks @threepointone! - fix (internal): fix infinite loop when developing

We use node's watch mode when developing partykit itself. On node 20, this just goes into an infinite loop, because it restarts on any writes, even if the file hasn't changed (iiuc). We are compiling facade/source.ts to facade/generated.js, while also watching the facade folder, which was triggering the restarts. I moved the outout to dist/generated.js, which fixes the problem.

#435 8fdb63f Thanks @threepointone! - add a default compatibility date

We should be adding a default compatibility date to new projects. Further, for projects that don't have one, we should warn that they should, and default to the latest compatibility date that we can. This PR adds that behaviour for both create, dev and deploy

#426 360c80a Thanks @threepointone! - Add --force/-f flag to partykit delete

Fixes https://github.com/partykit/partykit/issues/425

#436 645edd6 Thanks @threepointone! - update dependencies

#436 645edd6 Thanks @threepointone! - fix (internal): fix infinite loop when developing

We use node's watch mode when developing partykit itself. On node 20, this just goes into an infinite loop, because it restarts on any writes, even if the file hasn't changed (iiuc). We are compiling facade/source.ts to facade/generated.js, while also watching the facade folder, which was triggering the restarts. I moved the outout to dist/generated.js, which fixes the problem.

#435 8fdb63f Thanks @threepointone! - add a default compatibility date

We should be adding a default compatibility date to new projects. Further, for projects that don't have one, we should warn that they should, and default to the latest compatibility date that we can. This PR adds that behaviour for both create, dev and deploy

#431 af40d14 Thanks @threepointone! - fix: don't add --enable-source-maps in create-partykit's prod build

#436 645edd6 Thanks @threepointone! - update dependencies

#400 2ed33de Thanks @threepointone! - pin dependencies

#402 18011e8 Thanks @jevakallio! - Change default login provider to "partykit"