[DevOps] Create ESLint rule to enforce usage of `getReasonPhrase` for HTTP status code error messages

[choden-dev]

[DevOps] Create ESLint rule to enforce usage of getReasonPhrase for HTTP status code error messages

Description

We need to implement an ESLint rule that enforces the consistent use of getReasonPhrase from the http-status-codes library when providing error messages related to HTTP status codes in our responses.

Current Problem

In our codebase, error messages are inconsistently defined. Some places use getReasonPhrase(StatusCodes.XXX) while others use hardcoded strings. This creates inconsistency in our error reporting and makes maintenance more difficult.

Expected Solution

• Create a custom ESLint rule that enforces the usage of getReasonPhrase when setting error messages
• The rule should detect when an error object is created with a hardcoded string while a status code is being set
• The rule should suggest using getReasonPhrase with the appropriate status code instead

Examples

❌ Disallowed:

this.setStatus(StatusCodes.NOT_FOUND);
return { error: "Resource not found" };

✅ Allowed:

this.setStatus(StatusCodes.NOT_FOUND);
return { error: getReasonPhrase(StatusCodes.NOT_FOUND) };

Implementation Notes

• Focus on controller methods that return error responses
• Look for patterns where this.setStatus() is called followed by returning an error object
• Consider checking for common error object patterns like { error: string }, { message: string }, etc.
• The rule should work with both direct status codes and StatusCodes enum usage

Acceptance Criteria

• ESLint rule correctly identifies instances where hardcoded error messages are used instead of getReasonPhrase
• Rule provides helpful error messages with suggestions to use getReasonPhrase
• Documentation for the rule is added to our development guidelines
• A plan for migrating existing code to comply with the new rule is established

BEFORE MERGING

• Acceptance criteria met
• PR Reviewed (For non-trivial changes)
• Changes tested after rebasing on master or merging in master (hint: git fetch origin master:master, then git rebase master or git merge master)
• All required PR checks passing