Refactor (packages/app/src/context/directory-sync.ts): Function with many returns

[ItsJayYip]

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue:
#13

Full path to the refactored file:
/opencode/packages/app/src/context/directory-sync.ts

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
I think this file manages the information tied to one project folder in the app. It helps keep track of things like which sessions belong to that folder, retrieving and updating those sessions, and archiving them when needed. When I say session, I mean something like an individual conversation or working session associated with that project folder. In simpler terms, it acts like an organizer that keeps a project folder’s session history and related information in sync and easy for the rest of the app to use.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
I changed the index() helper function, set() helper function, and the archive method. I reduced return statements where possible, so for instance there was a if-else statement with returns in each of them (2 return statements), but I just assigned them res = <corresponding returned statement>, and then wrote return res in the end.

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with many returns (count = 8) in createDirSyncContext()

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
Previously, the qlty tool emphasized that the high number of return statements was making the function really complex and hard to follow for somebody new to the codebase. This can directly negatively impact the maintainability because no developer wants to take vast amounts of time to simply understand a codebase that is written with too many return statements. Also, it can be harder to trace specific bugs if there is a lot of return statements to manage.

What changes did you make to resolve the issue?
I removed early return statements by inverting the if statements, collapsed two return statements into one return statement using a variable res. I drove down the number of returns from 8 to 5, and this number was when the qlty tool no longer warned me at this number.

How do your changes improve maintainability? Did you consider alternatives?
My changes improve maintainability by simplifying the control flow in the if-else statements, which in turn make the function easier to follow. Instead of multiple, consecutive if-then-else statements that led directly to return statements, I inverted conditions, so there is fewer return statements. After fixing the return statement qlty smell, I turned to the high complexity, where I tried the alternative of three helper functions. After implementing the three helper functions, the qlty smell complaints went away.

3. Validation

How did you validate that the change is correct?
bun lint and bun test contained no errors other than 6 warnings that were in an entire different directory. These 6 warnings were from the use export issue. I also consistently ran qlty to confirm both the high complexity and the too many returns were removed. I also wrote tests in a new file using other existing test files as reference. For example, there was a command.tsx file and a corresponding command-test.ts file, so I created imports and tests directly tied to the file I changed.

Attach a screenshot of the test coverage showing the lines were executed by the tests.

Attach a screenshot showing the tests that cover the change passing during CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.
Before:

After:

Gradescope checklist wanted bun lint and bun test screenshots (so here they are)