This PR replaces the extendable TLServer class with an instantiatable
wrapper for the TLSyncRoom called TLSocketRoom.
The goal is to provide an API where you pretty much just
1. create a room from some (optional) snapshot
2. pass websockets into it when they connect
And then lifecycle stuff and persistence stuff is left to the consumer,
since that all seems to be much more context dependent.
One thing remaining here is to work on observability. We had a slightly
messy situation regarding logging and error handling and analytics and I
want to clean that all up.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [x] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [x] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. Add a step-by-step description of how to test your PR here.
4.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
This PR switches up how PR labels are validated to allow for more
freeform label tweaking in the future. Basically **huppy will now only
check that your PR is labelled, it doesn't care how it's labelled**. I
also updated the PR template with a new labelling scheme that we can
tweak over time.
So before Huppy bot had to know about the specific set of allowed
labels, and now as long as the label exists you're allowed to add it.
So to add a new label to the PR template, just create the label and then
add an option for it in the .md file.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
