Migrate to partyserver (cloudflare/partykit) #59
Conversation
PartyKit was moved to `cloudflare/partykit` on github (from `partykit/partykit`), and the new packages had a 1.0.0 release two weeks ago. This commit migrates to the new `partyserver` package replacing `partykit`, and `y-partyserver` replacing `y-partykit`. This probably needs a major version bump, as I didn't see any guarantee of compatibility with the old PartyKit, though it was pretty close to compatible, at least. Old clients will definitely not be compatible, as I decided to use YServer's new CustomMessage API instead of overriding onMessage, since the old way of sending playhtml-layer messages relied on PartyKit just incidentally not using text websocket messages.
We check in only the generated types without the runtime. This means there are still some type errors related to the Cloudflare Workers API, because we are still using `@cloudflare/worker-types`, which has been deprecated.
Fix onLoad discarding the newly loaded document
|
Fixed a bug with loading from DB. I haven't tested this PR with supabase yet (I probably will this week). |
|
thanks for making this! my main worry with that we don't run into any data loss. im gonna check in with the partytkit authors to get a second pair of eyes |
| "changeset": "changeset", | ||
| "version-packages": "changeset version", | ||
| "release": "bun run build-packages && changeset publish", | ||
| "generate-types": "bunx wrangler types --include-runtime=false", |
There was a problem hiding this comment.
It'd probably be even better to do --include-runtime=true as well, since @cloudflare/worker-types is mostly deprecated, and there seemed to be a couple type errors I couldn't seem to fix with @cloudflare/worker-types as well.. I just wanted to run that by you first. That flag generates more accurate types for the entire runtime, based on the compatibility_date you set in the wrangler config.
If you wanna do that, I'd also ask if you rather have the worker-configuration.d.ts checked in to the repo or generated at compile-time.
That makes sense. I can also give it a second pass with data migration in mind if you want, as I didn't really do that for this draft. |
|
hi @jessa0 sorry for the delay here! couldn't get a hold of the partykit folks but i think it should be fine since im persisting the data separately anyways. going to actually take a look this week. thanks for putting this up again! |
|
@jessa0 im actually curious - could you try deploying this as you originally desired and swapping in your provider URL for use with the playhtml library and seeing if everything works? If there is danger of compatibility for me switching the main partykit server while the partyserver package is still in development to parity, we can hold off on merging this in, but that doesn't stop you from using this version to do your own on-prem since you'd just be swapping in the provider URL |
2 participants
PartyKit was moved to cloudflare/partykit on github (from partykit/partykit), and the new packages had a 0.1.0 release two weeks ago. This PR migrates to the new
partyserverpackage replacingpartykit, andy-partyserverreplacingy-partykit.This probably needs a major version bump, as I didn't see any guarantee of compatibility with the old PartyKit, though it was pretty close to compatible, at least. Old clients will definitely not be compatible, as I decided to use YServer's new CustomMessage API instead of overriding onMessage, since the old way of sending playhtml-layer messages relied on PartyKit just incidentally not using text websocket messages. Please let me know if I should create a changeset.
Motivation: I am experimenting with playhtml, but wanted to deploy in the "cloud-prem" configuration (PartyKit on own cloudflare account). I got stuck with PartyKit not being able to deploy to a free Cloudflare account, and noticed advice from the PartyKit authors (but can't find the link to that conversation, sorry..) to migrate to
cloudflare/partykitinstead. So I went down that rabbit hole..