Merge branch 'master' into fix/issue-#4

.github/workflows/jest.yml

@@ -0,0 +1,31 @@
+name: Backend tests
+
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  jest-unit-tests:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v2
+
+    - name: Set up Node.js
+      uses: actions/setup-node@v2
+      with:
+        node-version: '20'
+
+    - name: Install backend dependencies
+      working-directory: ./backend
+      run: npm install
+
+    - name: Run backend test suite
+      working-directory: ./backend
+      run: npm run test

ARCHITECTURE.md

@@ -1,4 +1,4 @@
-# Communication between client and server
+# Communication between the client and the server
 
 Apart from the initial request-response exchange for initial setup,
 the client and server communicate using a simple message-based

CONTRIBUTING.md

@@ -43,7 +43,11 @@ Given that you have already forked the repository and set it up locally:
    - Make the necessary changes to fix the issue. Follow the existing code style and conventions. Please refer to the code style and conventions in [CONVENTIONS.md](CONVENTIONS.md).
 
 7. **Test Your Changes**:
-   - Thoroughly test your changes to ensure they work as intended and do not introduce any new bugs.
+   - Thoroughly test your changes manually to ensure they work as intended and do not introduce any new bugs.
+   - You can write unit tests for backend changes whenever required. Your changes should not cause existing tests to fail.
+   - Adhere to the eslint suggestions and use prettier to format code before committing. 
+   Running `npm run fix-format` in both the frontend and the backend will format all the files using prettier.
+
 
 8. **Commit Your Changes**:
    - Please refer to the commit message guidelines in [CONVENTIONS.md](CONVENTIONS.md#commit-message-guidelines) for writing meaningful commit messages.
@@ -67,7 +71,7 @@ Given that you have already forked the repository and set it up locally:
 
 - Editing commit history and rebasing are very valuable tools for keeping the commit history clean and easy to understand. Please familiarize yourself with these concepts before contributing. In any case, the seniors will be there to help you out.
 - Before starting work, run `git fetch upstream` and then `git rebase upstream/master`, to rebase your branch on top of the main branch. This will help you avoid merge conflicts, and sync your branch with the main branch.
-- Addressing reviews on existing PRs is as important as creating new PRs. Please be responsive to the feedback and make the necessary updates.
+- Addressing reviews on existing PRs is more important than creating new PRs. Please be responsive to the feedback and make the necessary updates.
 - Create a new branch for each issue you are working on. This will help you keep your changes isolated and make it easier to manage multiple PRs. The branch should be created from upstream/master, and only after fetching the latest changes from the main branch from upstream first.
 
 ## Common Git Operations you may need to perform
@@ -153,6 +157,10 @@ This will open VSCode whenever you run a command that requires a text editor, li
 
 All contributions go through a code review process to ensure the quality and maintainability of the codebase. During the review, maintainers may provide feedback or request changes to your code. Please be responsive to the feedback and make the necessary updates. There may be multiple rounds of review before your changes are approved.
 
+When you open a pull request, you can request a review from the maintainers. You can also request a review after making changes in resopnse to feedback. The requested reviewer may then review the PR themselves or delegate to another maintainer.
+
+Your PR will be merged only after the maintainers approve it. Different areas of codebase are handled by different maintainers.
+
 ## Code of Conduct
 
 Please note that this project is governed by our [Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.

CONVENTIONS.md

@@ -13,8 +13,9 @@
 
 ## For React Components
 - Use functional components with hooks instead of class based components.
+- Component names here should be in PascalCase.
 - Avoid copy pasting code. If you find yourself copying and pasting code, consider refactoring it into a reusable component or function. Use array methods like `map`, `filter`, and `reduce` to avoid duplicating code.
-- Try to use tailwind for css styling as much as possible. If you need to write custom css, use CSS modules. Avoid using global styles, unless they actually need to be global. Take `input.tsx` as reference.
+- Try to use tailwind for css styling as much as possible. If you need to write custom css, use CSS modules. Avoid using global styles, unless they actually need to be global.
 
 
 ## Commit Message Guidelines
@@ -26,7 +27,7 @@
     ```
     <area_of_code>: <short_description>
     
-    <detailed_description>
+    <detailed_description, preferably in points>
 
     Fixes: #<issue_number> (omit this if there is no issue associated with the commit)
     ```
@@ -35,7 +36,8 @@
     server: Add endpoint to fetch user data.
 
     This commit adds a new endpoint to the server that allows clients to fetch user data.
-    We fetch the user data from MongoDB and return it as a JSON response, filtering out sensitive information.
+    We fetch the user data from MongoDB and return it as a JSON response, filtering out
+    sensitive information.
 
     Fixes #28626
     ```
@@ -47,13 +49,38 @@
 
     ```
 
+### Preparatory Commits
+Preparatory commits are commits that prepare the codebase for a new feature or fix. They should not contain any functional changes. They can include things like:
+- Exporting a function from a module.
+- Renaming a variable or function.
+- Other such changes that do not affect the functionality of the code.
+
+The commit message for preparatory commits should be the same as normal commits, but the commit description should mention that it is a preparatory commit for an issue. The Fixes clause is omitted, because the commit doesn't actually fixes the issue.
+
+Example:
+```
+client: Refactor button component.
+
+This commit adds a `backgroundColor` prop to the button component to allow users to customize the background color of the button. This is in preparation to #12345.
+```
+
 ## Other Important Points
 - Use meaningful and descriptive names for variables, functions, and classes to enhance code readability.
 - Follow consistent indentation and formatting throughout the codebase (will be enforced by ESLint and prettier).
 - Use proper spacing and line breaks to improve code readability.
+- All the global variables should be declared above the functions in the respective file.
 - Avoid unnecessary code duplication and strive for code reusability.
 - Write clear and concise documentation for public APIs and important functions. Do not over-document trivial functions.
 - We are using TypeScript in a very lenient and flexible setting. The project can have both JS and TS files, and one of the goals would be to convert all files to TS eventually. Where you are not using types.
-- Try to keep the use of external dependencies to a minimum. This is because the purpose of project is first to learn and then to build. So, we will try to build as much as possible from scratch.
+- Try to keep the use of external dependencies to a minimum. This is because the purpose of project is first to learn and then to build. So, we will try to build as much as possible from scratch. That way there are more issues to work on.
 
 Remember to review and adhere to these conventions to maintain a clean and consistent codebase.
+
+## Testing
+We use `jest` for backend tests. You can run the tests using the following command:
+```bash
+cd backend
+npm run test
+```
+
+For testing a function using `jest`, you have to export it from the module.

README.md

@@ -17,3 +17,5 @@ This project is a multiplayer UNO game built using the MERN (MongoDB, Express, R
 - **Node.js**: To run the server-side code and manage dependencies.
 - **Socket.IO**: For real-time communication between players in the game rooms.
 
+Additionally, we use `jest` for backend tests. 
+

backend/.eslintignore

@@ -0,0 +1,4 @@
+/.eslintrc.js
+/node_modules/*
+/dist/*
+/tests/*

backend/.eslintrc.json

@@ -0,0 +1,19 @@
+{
+    "env": {
+        "browser": true,
+        "es2021": true
+    },
+    "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
+    "parser": "@typescript-eslint/parser",
+    "parserOptions": {
+        "ecmaVersion": "latest",
+        "sourceType": "module"
+    },
+    "plugins": ["@typescript-eslint"],
+    "rules": {
+        "indent": ["error", 4],
+        "linebreak-style": ["error", "unix"],
+        "quotes": ["error", "single"],
+        "semi": ["error", "always"]
+    }
+}

backend/.prettierrc

@@ -2,5 +2,6 @@
     "singleQuote": true,
     "trailingComma": "es5",
     "tabWidth": 4,
-    "semi": true
+    "semi": true,
+    "endOfLine": "lf"
 }

backend/jest.config.js

@@ -0,0 +1,6 @@
+module.exports = {
+    transform: { '^.+\\.d?ts?$': 'ts-jest' },
+    testEnvironment: 'node',
+    testRegex: '/tests/.*\\.(test|spec)?\\.(ts|tsx)$',
+    moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
+};