P1B: Refactor (packages/opencode/src/cli/cmd/run/footer.ts:122): Function with many returns (count = 8): eventPatch - #105
Open
halhajricmu wants to merge 1 commit into
Conversation
halhajricmu
force-pushed
the
refactor/footer-eventpatch-many-returns
branch
from
September 6, 2026 17:17
d8f820d to
de6c7ec
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to the associated GitHub issue: Closes P1B: Refactor (packages/opencode/src/cli/cmd/run/footer.ts:122): Function with many returns (count = 8): eventPatch #99
Full path to the refactored file: packages/opencode/src/cli/cmd/run/footer.ts
What do you think this file does? Implements RunFooter, the mutable footer UI for opencode run interactive mode — it owns the append-only scrollback stream and the reactive footer state (prompt, status, permission/question views) and turns incoming FooterEvents into state patches.
What is the scope of your refactoring within that file?
Only the module-level function eventPatch(next: FooterEvent): FooterPatch | undefined (previously lines 122–165). No other function touched.
Which Qlty-reported issue did you address? The "Function with many returns (count = 8): eventPatch" smell at footer.ts:122.
How did the specific issue you chose impact the codebase's maintainability? The 8 separate return points made the function hard to scan and easy to break when adding a case.
What changes did you make to resolve the issue? Replaced the if/return chain with one switch (next.type) that assigns to a single patch local and returns once at the end. TypeScript still narrows each case, so every branch produces the exact same value as before; unhandled types fall through to the initial undefined. How do your changes improve maintainability? Did you consider alternatives? One exit point and a case per event type makes the event→patch mapping readable at a glance. Alternative considered: a lookup object keyed by type, but the per-case payloads differ and rely on union narrowing, so a switch stays clearer with no casts.
How did you validate that the change is correct? Behaviour is identical by construction (same 7 cases → same patches). Added packages/opencode/test/cli/run/footer.event-patch.test.ts with one assertion per handled event type plus the undefined fallback; bun test passes locally and in CI. Re-ran qlty smells --no-snippets on the file and the eventPatch "many returns" finding is gone.
Coverage, local test run, and qlty smells (before / after):
Tests passing during CI (GitHub Actions):
