Skip to documentation
Documentation navigation

Documentation navigation

Documentation / build

Build 10: workspaces and release boundaries

Keep released module versions reproducible while using the coordinated source workspace for development and verification.

developer

The Looprig checkout can coordinate many modules, but a released module must remain reproducible outside that checkout. Build and publish against immutable dependency versions; use workspace wiring only for development and for the examples that intentionally exercise the coordinated source tree.

Released modules

A released module has a versioned go.mod dependency and an immutable tag. Core, Secrets, Credentials, Storage, Fsstore, Natsstore, Rclonestore, Sandbox, Flow, flow/store, Inference, LLM, Eval, Workflows, and Client each have release records in this corpus. A consumer should use those versions and run its checks with GOWORK=off so a local checkout cannot mask a missing or incompatible dependency.

Source-workspace modules

The browser SDK packages under client/sdk are the remaining exception in this set. @looprig/client and @looprig/svelte are private npm packages with no published version, so they must be labelled source-workspace and must not be presented as installable. A nested Go module is not an exception: flow/store has its own go.mod and is published from the Flow repository at its own store/ tag, on its own cadence, so a consumer pins that tag rather than a filesystem replacement.

Verification boundary

Run each module’s native tests and examples with its own module boundary, then run the progressive examples from the workspace. Check that generated artifacts, storage roots, NATS processes, and provider fixtures are cleaned up by the example manifest. When a source-workspace example is intentional, record that fact in the example metadata rather than presenting it as an installable release path.

Choosing a workspace

Use Fsstore for a local single-process path when an explicit root and file durability are appropriate. Use Storage interfaces in application code so Natsstore or another backend can be substituted later. Keep workspace layout, local replacement rules, and release versions separate from runtime ownership of stores, clients, and model credentials.

Runnable proof

stage-08-session-store proves the released Fsstore path and stage-10-workspace proves a Storage snapshot round trip. Run them with node scripts/docs/run-examples.mjs, then repeat relevant module tests with GOWORK=off. Source trees are pinned in the Storage release and Fsstore release. The referenced package pages list the pinned source files and adjacent tests used for these workspace boundaries.

← back to documentation