@slake-dev/server
v1.1.3
Published
Backend server for Slake — handles real-time sync via Socket.IO, annotation storage, and GitHub integration.
Readme
@slake-dev/server
Backend server for Slake — handles real-time sync via Socket.IO, annotation storage, and GitHub integration.
Install
npm install @slake-dev/serverUsage
Start the server:
npx slake-serverEnvironment variables
| Variable | Default | Description |
|---|---|---|
| PORT | 4000 | Server port |
| SLAKE_ALLOWED_ORIGINS | http://localhost:3000,http://localhost:4000,http://localhost:5173 | Comma-separated CORS origins |
| SLAKE_ORIGIN_ALIASES | — | Comma-separated alias=canonical pairs that share a room (see below) |
| GITHUB_TOKEN | — | GitHub personal access token for issue creation |
Origin aliases (sharing a room across tunnels)
By default, rooms and storage are scoped per origin so two apps on the same
backend stay isolated. That means http://localhost:3000 and an ngrok tunnel
pointing at it are treated as different rooms, and users on each can't see
each other.
Set SLAKE_ORIGIN_ALIASES to map alias origins to a canonical origin. All
matched origins land in the same room and share annotations:
SLAKE_ORIGIN_ALIASES=https://abc123.ngrok-free.dev=http://localhost:3000Multiple aliases (e.g. one tunnel per teammate) can map to the same canonical:
SLAKE_ORIGIN_ALIASES=https://abc.ngrok-free.dev=http://localhost:3000,https://xyz.ngrok-free.dev=http://localhost:3000When at least one alias is configured, the server logs a one-time warning if an unaliased origin connects, suggesting the env var to add.
Migration of pre-alias data. Annotations created from an alias origin
before SLAKE_ORIGIN_ALIASES was configured were stored under the alias's
own slug, not the canonical's. The server lazily migrates these on
user-join: when a user joins from an alias origin and the canonical room is
empty for that pathname, any annotations under the alias slug are copied over.
This mirrors the legacy unscoped-pathname migration and, like that one,
covers annotations only — pre-alias threads and replies under alias
slugs remain orphaned. In practice this rarely matters because tunnel URLs
are usually ephemeral, but if you have long-lived tunnels (paid ngrok
reserved domains, etc.) and need full thread migration, file an issue.
