ora

Description Ora's mutable and flags can prevent completion methods from restoring state that changed. currently returns before calling when is true, leaving the animation interval active. Separately, only restores the cursor when is currently true, so disabling output after can leave the cursor hidden. Steps to reproduce Expected behavior Completion methods always stop the spinner and restore terminal state, while silent mode suppresses persisted output rather than lifecycle cleanup. Actual behavior can leave , and can skip cursor restoration after is changed. A focused fix now tracks whether hid the cursor and calls before the silent-output early return. Regression tests for both cases pass locally. I searched existing issues and pull requests for these state transitions and did not find a matching report.

computes how many terminal rows the current text wraps to using at the moment it runs, and caches the result in . It's only ever called from the // / setters — never in response to a terminal resize. (called at the top of every , i.e. every animation frame) uses that cached to move the cursor up and erase the previous frame. If the terminal is resized while the spinner is running and the text is long enough to wrap across multiple rows, the actual wrapped row count changes but the cached one doesn't — so every subsequent erases the wrong region of the screen. This isn't a one-frame glitch: since is never recomputed for the rest of that spinner's life, the desync is permanent and can progressively corrupt unrelated terminal content above/around the spinner. Repro Observed: subsequent frames overwrite/interleave fragments of the message into adjacent rows instead of cleanly redrawing in place. Environment ora 8.2.0 Found via @sourcegraph/cody's (real-world discovery), reproduced directly against ora in isolation Windows 11, ConPTY-backed terminal — the bug itself isn't Windows-specific (it's pure line-math), but I haven't personally reproduced on macOS/Linux Suggested fix Recompute from the current inside right before using it (or listen for the stream's event while spinning and call then), rather than relying on a value cached at the last //etc. assignment.