feat: Integrate Prettier for Code Formatting and CI Check

[Rahul-R79]

Use Case

The current codebase uses ESLint not just for code quality (bugs), but also for formatting rules (indentation, quotes, spacing). This has two downsides:

1. Rigidity: It mixes stylistic concerns with quality checks, often leading to "fighting the linter."
2. Inconsistency: There is no dedicated formatting tool or CI check that enforces a strictly consistent "pretty" standard (like line wrapping) across all contributors and editors.

We want to separate these concerns: let ESLint handle bugs, and let Prettier handle style.

Possible Solution

I propose integrating Prettier into the project to handle all code formatting.

Implementation Details:

1. Dependencies:

   • Add prettier (v2+)
   • Add eslint-config-prettier (to disable conflicting ESLint formatting rules).

2. Configuration (.prettierrc):
   Add a config file to enforce a modern, consistent style:

   {
     "semi": true,
     "trailingComma": "es5",
     "singleQuote": true,
     "printWidth": 80,
     "tabWidth": 2,
     "useTabs": false
   }

   Note: I propose switching to 2-space indentation (modern standard) instead of the current 4, which improves readability for deeply nested code.

3. Scripts (package.json):

   • npm run format: Runs prettier --write . to auto-fix all files.
   • npm run format:check: Runs prettier --check . for CI to verify compliance.

4. CI Integration (.github/workflows/build.yml):

   • Add a step npm run format:check immediately after dependency installation.
   • If a developer pushes code with incorrect formatting, the CI build will fail immediately, safeguarding the codebase's quality.

Context

I have already implemented this in a fork and verified that it works.

• Alternatives Considered: We could stick with ESLint, but it lacks the robust auto-formatting capabilities of Prettier. We could also keep 4-space indentation, but moving to 2 spaces is a standard modernization step for valid JS/TS projects.
• Verification: I have tested this locally (running npm test) to ensure the reformatting does not break any logic or existing tests.

Detailed Description

This change will involve a one-time reformatting of the codebase (touching ~130+ files).

• Impact: Large diff in git history.
• Mitigation: After merging, we can add the commit hash to a .git-blame-ignore-revs file. This tells GitHub to ignore the "formatting commit" when viewing git blame, preserving the original authorship history.