testing/cross_backend/ts_spine_backend_config.ts

Cross-process BackendConfig presets for fuz_app's domain-free TS spine test binary (src/test/cross_backend/testing_spine_server_{node,deno,bun}.ts).

The TS analog of rust_spine_stub_backend_config (which spawns the Rust spine): these spawn fuz_app's own TS impl over real HTTP with no domain layer, so the cross_backend_ts_node / cross_backend_ts_deno / cross_backend_ts_bun self-test projects verify fuz_app's wire path in its own repo across all three JS runtimes. All run against in-memory PGlite (memory://) — no external Postgres, unlike the Rust path.

The binary writes its daemon token to {FUZ_TESTING_TS_SPINE_DIR}/run/daemon_token; anchoring the dir to paths.root makes that equal paths.daemon_token_path, which spawn_backend reads after the health probe.

view source

Declarations
#

11 declarations

ts_spine_bun_backend_config
#

testing/cross_backend/ts_spine_backend_config.ts view source

(options?: TsSpineBackendConfigOptions): BackendConfig import {ts_spine_bun_backend_config} from '@fuzdev/fuz_app/testing/cross_backend/ts_spine_backend_config.js';

BackendConfig for the Bun TS spine binary — spawned via bun run. Bun resolves the entry's relative .js.ts source specifiers natively (no flag needed — unlike Deno's --sloppy-imports, and like Gro's loader on the Node path), and Bun.serve + hono/bun need no extra deps.

options

default {}

returns

BackendConfig

TS_SPINE_BUN_DEFAULT_PORT
#

TS_SPINE_BUN_ENTRY
#

ts_spine_deno_backend_config
#

testing/cross_backend/ts_spine_backend_config.ts view source

(options?: TsSpineBackendConfigOptions): BackendConfig import {ts_spine_deno_backend_config} from '@fuzdev/fuz_app/testing/cross_backend/ts_spine_backend_config.js';

BackendConfig for the Deno TS spine binary. The --allow-* set mirrors the cross-process needs (net + read/write for the daemon-token file + env + sys); --unstable-detect-cjs matches the ecosystem's Deno test entries.

--sloppy-imports is required because the binary imports fuz_app source via relative .js specifiers (the src/lib convention) — Deno resolves .js.ts only under this flag, whereas Gro's loader (the Node path) does so natively. (zzz's Deno entry sidesteps it by importing fuz_app as a built package; this binary tests live source instead.)

options

default {}

returns

BackendConfig

TS_SPINE_DENO_DEFAULT_PORT
#

TS_SPINE_DENO_ENTRY
#

TS_SPINE_DIR_ENV
#

ts_spine_node_backend_config
#

TS_SPINE_NODE_DEFAULT_PORT
#

TS_SPINE_NODE_ENTRY
#

TsSpineBackendConfigOptions
#

testing/cross_backend/ts_spine_backend_config.ts view source

TsSpineBackendConfigOptions import type {TsSpineBackendConfigOptions} from '@fuzdev/fuz_app/testing/cross_backend/ts_spine_backend_config.js';

port?

Listening port. Defaults per runtime (1178 Node, 1179 Deno, 1180 Bun).

type number

readonly

database_url?

Database URL. Default 'memory://' (in-memory PGlite).

type string

readonly

enable_login_rate_limit?

Enable the per-IP + per-account login rate limiters on the spawned binary (FUZ_LOGIN_RATE_LIMIT_ENABLED=true). Off by default — the standard cross suites fire many loopback logins a live limiter would 429. Set true only for the dedicated login-security cross project (global_setup_login_security.ts), which drives the 429 + Retry-After path and XFF-keyed bucketing over the wire (login_security.ts). The binary always wires trusted_proxies for 127.0.0.1/::1, so the limiter keys on the resolved X-Forwarded-For client IP. Mirrors SpineStubBackendConfigOptions.enable_login_rate_limit.

type boolean

readonly

Depends on
#