Install, runtimes, peers

npm  install -D foldcase@alpha    # or pnpm add -D / yarn add -D
bun  add     -d foldcase@alpha

Releases go out under the alpha dist-tag while the API can still break, so ask for it by name. Foldcase ships as a compiled dist/ — one .js and one .d.ts per source file, built by plain tsc, no bundler — so npm, pnpm, Vite and Bun all consume it as ordinary ESM. There is no single-file binary, and deliberately so: a compiled binary could never load a *.showcase.ts from your project, which is the tool's whole job (ADR-0002 › Amendment 1).

Two bins, one per runtime:

Both run the same program; only the shell around it differs.

Peer dependencies

• effect v4 — a peer dependency, so your app and Foldcase share one Effect instance. The range is >=4.0.0-beta.90, and both ends of it are run: the suite passes on the floor and on 4.0.0-beta.102, the version Foldkit pins today.

• One @effect/platform-*, matched to the Effect beta your app pins. Ask for the version by name:

  bashCopy

  bun add -d @effect/platform-node@4.0.0-beta.102   # or @effect/platform-bun@…

  latest on both packages is still the v3 major, and installing it pulls in a @effect/cluster built against Effect v3. The bin then dies inside a dependency you never asked for — Cannot find module 'effect/dist/FiberRef.js' imported from @effect/cluster — long before it reads a showcase. Both platform packages are optional peers: install only the one your bin runs. Without it, the bin names the package and the install command instead of printing a resolver stack trace.

• Node on PATH — only for foldcase test --coverage. Under the Node bin you already have it.

Foldcase does not depend on Foldkit. The play thunk is opaque to the runner, so Foldkit Showcases run in your app's own closure while Foldcase stays framework-blind.

Foldcase is alpha. Any patch may break the public API.