@spooky-sync/cli 0.0.1-canary.343 → 0.0.1-canary.346

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/AGENTS.md +26 -0
  2. package/package.json +6 -6
package/AGENTS.md CHANGED
@@ -163,6 +163,32 @@ apps:
163
163
  - "gomod:/go"
164
164
  ```
165
165
 
166
+ ## Worker backends (`apps.<name>.worker`)
167
+
168
+ A `type: backend` app with a `worker:` block runs, on a Cloudflare project, as a Dynamic Worker
169
+ inside the project's SSP Worker instead of a Docker container. It is still a sp00ky backend: it
170
+ needs `spec` and an outbox `method` with a `table`, and jobs reach it at `worker://<name>` (the SSP
171
+ POSTs the payload as JSON, with `Authorization: Bearer <auth.token>` when `auth` is set). Only the
172
+ paths in `expose` are public, on `https://<slug>.<domain>`. Keys: `entry` (required),
173
+ `compatibilityDate` (default `2026-10-01`), `compatibilityFlags`, `textModules` (globs imported as
174
+ strings), `cpuMs` (1..300000), `ai` (env binding for Workers AI), `workflows: [{binding, class}]`
175
+ (Cloudflare Workflows; the class is exported from the entry), `expose` (trailing `*` = prefix).
176
+
177
+ - Validation (`WorkerDeployConfig::validate`, `AppConfig::validate_worker` in `src/backend.rs`):
178
+ `hosting: external` and `runOn` are refused; bindings must not repeat. `spky lint`
179
+ (`Sp00kyConfig::worker_lint`) errors on a missing `entry` and warns on `baseUrl` (unused on
180
+ Cloudflare, though `spky dev` uses it), on `expose` overlapping a spec path, and on a manifest
181
+ that can only target VMs.
182
+ - `spky deploy` on a Cloudflare project (`deploy_worker_backend_cloudflare` in `src/cloud.rs`)
183
+ bundles `entry` with a pinned `npx esbuild` (platform neutral; `node:*`, `cloudflare:*` and, under
184
+ `nodejs_compat`, bare Node builtins stay external), uploads it by sha256, and sends
185
+ `worker_backends` in the deploy body. On a VM project the block is ignored with a warning and the
186
+ Dockerfile path runs.
187
+ - The backend's env (the `SPKY_*` base plus its own `env`, vault resolved) reaches it as plain
188
+ strings. No other Cloudflare bindings. `spky dev` does not run it under workerd: it runs from its
189
+ `dev` command at its `baseUrl`, like any backend.
190
+ - Runtime side: `apps/ssp-cf/js/host.mjs`. User docs: `docs/backend/workers.mdx` on the site.
191
+
166
192
  ## Sync transport (`sync.transport`)
167
193
 
168
194
  `sync.transport: changefeed` changes what the schema pipeline emits, in three
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@spooky-sync/cli",
3
- "version": "0.0.1-canary.343",
3
+ "version": "0.0.1-canary.346",
4
4
  "description": "Generate TypeScript/Dart types from SurrealDB schema files",
5
5
  "type": "module",
6
6
  "main": "./dist/syncgen.cjs",
@@ -62,10 +62,10 @@
62
62
  "vitest": "^1.0.0"
63
63
  },
64
64
  "optionalDependencies": {
65
- "@spooky-sync/cli-darwin-arm64": "0.0.1-canary.343",
66
- "@spooky-sync/cli-darwin-x64": "0.0.1-canary.343",
67
- "@spooky-sync/cli-linux-arm64": "0.0.1-canary.343",
68
- "@spooky-sync/cli-linux-x64": "0.0.1-canary.343",
69
- "@spooky-sync/cli-win32-x64": "0.0.1-canary.343"
65
+ "@spooky-sync/cli-darwin-arm64": "0.0.1-canary.346",
66
+ "@spooky-sync/cli-darwin-x64": "0.0.1-canary.346",
67
+ "@spooky-sync/cli-linux-arm64": "0.0.1-canary.346",
68
+ "@spooky-sync/cli-linux-x64": "0.0.1-canary.346",
69
+ "@spooky-sync/cli-win32-x64": "0.0.1-canary.346"
70
70
  }
71
71
  }