Repository navigation
chore: single-app cleanup — track overlay lockfile, fix electron dep, drop dead audio_level path - #69
Conversation
The root bun.lock is tracked but the overlay workspace's was not, so overlay dependency resolution was unpinned across machines and CI.
The app launcher spawns overlay/node_modules/.bin/electron as the process runtime (src/cli/app-launcher.ts), so electron is load-bearing at runtime, not just for the overlay's tsc build. Declared as a devDependency it would be absent from any production/--omit=dev install and the app could not launch.
The daemon computed an RMS/peak audio level per PCM chunk, throttled it to 30fps, smoothed it with an EMA, and shipped it main -> renderer as an audio_level IPC message. Nothing consumed it: the overlay's LiveWaveform runs its own getUserMedia + Web Audio AnalyserNode, and App.tsx never read the audioLevel the hook exposed. The path existed for the native GTK overlay (PR #65, closed as superseded by ADR-0003), which had no Web Audio and needed levels computed host-side. Removes the producer (AudioRecorder.getAudioLevel and its 'level' event), the relay (DaemonService.handleRecorderLevel, the EMA fields, the 33ms throttle), the transport (AudioLevelMessage, the main->renderer forward, the preload bridge), and the dead renderer state in useDaemonState.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (9)
💤 Files with no reviewable changes (4)
📝 WalkthroughWalkthroughThe audio-level event pipeline was removed from the recorder, daemon, IPC contracts, Electron bridge, and renderer hook. Daemon state events remain available, and Electron is now a runtime dependency for the overlay. ChangesAudio-Level Pipeline Removal
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
Post-Phase-1 cleanup (follows #68). Three independent commits, no behaviour change intended.
1.
chore(overlay): track bun.lockThe root
bun.lockis tracked but the overlay workspace's was not, leaving overlay dependency resolution unpinned across machines and CI.2.
fix(overlay): declare electron as a runtime dependencysrc/cli/app-launcher.ts:10spawnsoverlay/node_modules/.bin/electronas the app's process runtime, so electron is load-bearing at runtime — not just for the overlay'stscbuild. Declared as adevDependencyit would be absent from any production /--omit=devinstall and the app could not launch at all. The comment atapp-launcher.ts:8already asserted "the Electron runtime is the overlay package's dependency"; this makes the manifest match. Lockfile diff is a pure reclassification — no version drift, no new packages.3.
refactor: remove the vestigial daemon audio_level pathThe daemon computed an RMS/peak level per PCM chunk, throttled to 30fps, smoothed with an EMA, and shipped it main → renderer as an
audio_levelIPC message. Nothing consumed it:overlay/src/renderer/LiveWaveform.tsxruns its owngetUserMedia+ Web AudioAnalyserNode, andApp.tsxnever read theaudioLevelthe hook exposed. The path existed for the native GTK overlay (#65, closed as superseded by ADR-0003), which had no Web Audio and needed levels computed host-side.Removed end to end: producer (
AudioRecorder.getAudioLevel+levelevent), relay (DaemonService.handleRecorderLevel, EMA fields, 33ms throttle), transport (AudioLevelMessage, main→renderer forward, preload bridge), and dead renderer state inuseDaemonState.docs/ARCHITECTURE.mdupdated to match; the ADR-0003 mention was left intact as a dated historical record of what Phase 1 landed.Verification
bun run typecheck+bun run typecheck:app— cleanbun run test— 240/240 vitest passbun test— 252/252 bun passbun run build:overlayandbun run build:app— both succeedbiome checkfindings identical to baseline (verified by diffing the uncapped github reporter output againstmain)Summary by CodeRabbit