Refactor (packages/server/src/handlers/project-copy.ts): Function with many returns

[tsuarez16]

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:
#157

Full path to the refactored file:
packages/server/src/handlers/project-copy.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 handles the API endpoints for copying, removing, and refreshing project directories on the server. The function, message(), allows these errors to feed back to the user.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
I only touched the message() function (lines 57–78), swapped the if-else checks with early returns for a switch on error._tag, learned and generated with AI, that assigns to one result variable and returns once at the end. Nothing else in the file (the ProjectCopyHandler handlers or badRequest()) was touched.

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

Refactor / Code Improvement: Function with many returns (count = 6) in message()

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
With 6 returns, it was easy to lose track of every exit point, and adding a 7th error type risked someone forgetting a return. Any shared logic (like logging) would've needed touching all 6 spots instead of one.

What changes did you make to resolve the issue?
I replaced the if-else chain with a switch on error._tag, assigning the message to a single result. Only one exit was possible, with the returning variable 'result' at the end. In addition, I added the export keyword to its declaration so the test file could import and call it directly.
Before:

After:

How do your changes improve maintainability? Did you consider alternatives?
One return point makes it easier to see what the function actually outputs, and adding a new error type is just one more case, not a whole new return. I thought about using a lookup map instead, but the errors have different fields, so it got messy, so I stuck with the switch.

3. Validation

How did you validate that the change is correct?
I generated unit tests in packages/server/test/project-copy.test.ts that call message(). In addition, I ran the bun commands as well as the qlty smells.

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


bun lint:

bun test:

Above are screenshots of the project copy. ts having 100% line coverage, and the 6 green checkmarks!

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.