A CLI command can run in different output modes depending on context. We want to decouple command state/logic from output rendering to enable code sharing and principled divergence.
Status: SOLVED - Use
link:protocol (primary) +enableGlobalVirtualStore(for remainingfile:deps)For a detailed comparison of bun vs pnpm monorepo linking behavior, see: https://gist.github.com/schickling/d05fe50fe4ffb1c2e9e48c8623579d7e
This document provides comprehensive context for reproducing and debugging a SIGTRAP crash that occurs when using LiveStore with Bun.
When creating and destroying ~100-180 LiveStore instances sequentially (each backed by SQLite WASM via wa-sqlite), Bun crashes with a SIGTRAP signal (Trace or breakpoint trap).
When a repo is used as a path flake input inside another repo’s devenv, devenv expects
<input>/.devenv.flake.nix to exist. If that file is untracked, it is not included in the
flake snapshot, so devenv shell fails with:
error: '/nix/store/<...>/effect-utils/.devenv.flake.nix' does not exist
Active investigation. The root cause is understood but the final workaround is not selected.
Playwright throws Error: Requiring @playwright/test second time when a shared config or helper package is linked via file: and both the consumer and the linked package resolve their own physical copies of @playwright/test. The Playwright runner enforces a singleton load and errors on the second physical path.
We need a fast, reliable, pure way to build Bun-based native CLIs from TypeScript that:
- works with dirty/uncommitted changes,
- avoids copying large trees like
node_modules, - works in flakes and devenv,
- keeps dirty builds close to clean build performance.
I’m investigating hardware-accelerated video decode on Raspberry Pi 5 using Chromium (Wayland). The goal is smooth playback (no frame drops) and a Chromium-based UI. So far, Chromium appears to run software-only for video decode/compositing on Pi 5, despite extensive flag and VA-API attempts.
- Hardware: Raspberry Pi 5 (BCM2712)
- OS/Display: Wayland (Sway/Wlroots)
- Browser: Chromium (aarch64)
- GPU: V3D
When RpcGroup.toLayer is called with Effect.succeed(handlers), the handler effect’s
requirements (R) are erased. This compiles even if a handler uses a service that is
never provided, and it fails at runtime with “Service not found”.
This repro shows:
- Unsafe pattern: compiles, but fails at runtime
When a leader session exits while a follower has pending events, the follower's attempt to become the new leader stalls indefinitely. This is caused by the Effect Worker mechanism not detecting worker termination and propagating it to pending streams.
Impact: Pending events remain stuck, GetLeaderSyncState times out after 1s.
Root Cause: Effect Worker streams don't error out when the underlying worker terminates, causing the SharedWorker to block new requests while old ones hang.