Upgrade package @testing-library/user-event from 12.8.3 to 13.5.0

[mohamedrehan1]

-solve failing tests resulting from upgrade testing-library/user-event'

issue #2072: #2072 (comment)

Summary by CodeRabbit

Release Notes

• New Features

  • Introduced a new configuration file for YAML language server settings.
  • Added .env.example file to guide environment variable setup for the Talawa-admin project.
  • Implemented a new README for GitHub workflows, detailing contribution guidelines.
  • Created new scripts for checking local storage usage and updating table of contents in Markdown files.
  • Added comprehensive localization support for multiple languages, including English, French, Hindi, Spanish, and Chinese.

• Documentation

  • Enhanced CONTRIBUTING.md and CODE_STYLE.md for clearer guidelines.
  • Added INSTALLATION.md to provide setup instructions for the Talawa-admin application.
  • Introduced DOCUMENTATION.md to guide users on documentation processes.

• Bug Fixes

  • Updated various templates and guidelines for issue reporting and pull requests for better clarity and usability.

[coderabbitai]

Walkthrough

The changes in this pull request introduce a variety of configuration files and scripts aimed at enhancing the development environment for the Talawa Admin project. Key additions include a YAML language server configuration, a template for environment variables, and various GitHub Actions workflows for CI/CD processes. The update also includes localization files for multiple languages, improvements to the ESLint configuration, and several utility scripts for managing code quality and documentation. Additionally, several files have been removed or modified to streamline the project structure.

Changes

File Path	Change Summary
.coderabbit.yaml	New configuration file for YAML language server with various settings.
.env.example	New template for environment variable configuration with essential variables for the Talawa-admin project.
.eslintignore	Added entry to ignore src/components/CheckIn/tagTemplate.ts from linting.
.eslintrc.json	Updated ESLint configuration with new plugins, rules, and support for Node.js.
.github/ISSUE_TEMPLATE/bug-report.md	Updated metadata fields and added new sections for additional details and internship candidates.
.github/ISSUE_TEMPLATE/feature-request.md	Updated metadata fields and added new section for internship candidates.
.github/dependabot.yaml	New configuration file for automated dependency updates using Dependabot.
.github/pull_request_template.md	Modified to enhance clarity and guidance for contributors.
.github/workflows/README.md	New README file outlining guidelines for contributing to GitHub workflows.
.github/workflows/auto-label.json5	New configuration file defining label synonyms and default labels for workflows.
.github/workflows/check-tsdoc.js	New script to validate TypeScript files for TSDoc comments.
.github/workflows/ci.yml	Deleted CI workflow file.
.github/workflows/codeql-analysis.yml	Deleted CodeQL analysis workflow file.
.github/workflows/codeql-codescan.yml	New workflow for automating CodeQL analysis on pull requests and pushes.
.github/workflows/compare_translations.py	New utility script to compare translation files.
.github/workflows/countline.py	New script to analyze code line counts in specified directories.
.github/workflows/eslint_disable_check.py	New script to check for eslint-disable statements in TypeScript files.
.github/workflows/issue.yml	Modified workflow for issue labeling and greeting users.
.github/workflows/linter.yml	Deleted linter workflow file.
.github/workflows/npm-publish.yml	Deleted workflow for publishing Node.js packages.
.github/workflows/pull-request-target.yml	New workflow for handling pull request greetings and review policies.
.github/workflows/pull-request.yml	New workflow for automated checks on pull requests.
.github/workflows/push.yml	New workflow for testing and code coverage calculations on code pushes.
.github/workflows/stale.yml	New workflow for managing stale issues and pull requests.
.github/workflows/talawa_admin_md_mdx_format_adjuster.py	New script for converting Markdown files to MDX format.
.gitignore	Updated to ignore additional files and directories.
.husky/post-merge	New script to run npm install if package.json changes are detected.
.husky/pre-commit	Added commands for formatting, linting, and staging files before commit.
.lintstagedrc.json	New configuration for linting and formatting tasks on staged files.
.node-version	New Node.js version specification added.
.prettierignore	Updated to ignore specific files from Prettier formatting.
.prettierrc	Added new property for handling line endings.
CODEOWNERS	New file designating the code owner for the repository.
CODE_OF_CONDUCT.md	Updated to include a Table of Contents and detailed enforcement guidelines.
CODE_STYLE.md	New document outlining the coding standards for the project.
CONTRIBUTING.md	Updated with a Table of Contents and restructured sections for clarity.
DOCUMENTATION.md	New documentation file outlining where to find project documentation.
Docker_Container/.dockerignore	Deleted file specifying files to ignore during Docker image builds.
Docker_Container/README.md	Deleted setup instructions for Docker container.
Docker_Container/docker-compose.yml	Deleted Docker Compose configuration for a sample service.
Docker_Container/dockerfile	Deleted Dockerfile for setting up a Node.js application.
INSTALLATION.md	New document providing setup instructions for the Talawa Admin application.
ISSUE_GUIDELINES.md	New document standardizing the issue reporting process.
PULL_REQUEST_TEMPLATE.md	Deleted pull request template file.
README.md	Updated with new community links, logo, and structured Table of Contents.
config/babel.config.cjs	New Babel configuration file for transforming modern JavaScript and TypeScript.
config/vite.config.ts	New Vite configuration file for building the React application.
index.html	New HTML file defining the structure of the web page.
schema.graphql	New GraphQL schema defining types, inputs, and directives for the application.
scripts/__mocks__/@dicebear/collection.ts	New Jest mock function for testing.
scripts/__mocks__/@dicebear/core.ts	New mock function for simulating avatar creation.
scripts/__mocks__/@pdfme/generator.test.ts	New test suite for the generate function from the @pdfme/generator package.
scripts/__mocks__/@pdfme/generator.ts	New mock function simulating PDF generation.
scripts/__mocks__/fileMock.js	New mock file for testing file imports.
scripts/custom-test-env.js	New custom Jest testing environment for supporting the @pdfme library.
scripts/githooks/check-localstorage-usage.js	New script to check for localStorage usage in the codebase.
scripts/githooks/update-toc.js	New script to update the table of contents in Markdown files.
setup.ts	New setup script for initializing the Talawa Admin application environment.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant SetupScript
    participant EnvFile
    participant API

    User->>SetupScript: Run setup
    SetupScript->>EnvFile: Check for .env file
    alt .env file not found
        SetupScript->>EnvFile: Create .env from template
    end
    SetupScript->>User: Prompt for custom port
    User->>SetupScript: Provide port
    SetupScript->>EnvFile: Update .env with port
    SetupScript->>API: Validate Talawa API URL
    User->>SetupScript: Provide API URL
    SetupScript->>EnvFile: Update .env with API URL
    SetupScript->>User: Setup complete

Loading

Possibly related issues

• Upgrade package @testing-library/user-event from 12.8.3 to 14.5.2 #2072: The changes in this PR may help address dependency upgrades that were previously attempted but failed in automated jobs.
• Upgrade @testing-library/jest-dom from 5.16.5 to 6.4.2 #1951: This issue involves upgrading a package that may require adjustments in the configurations, which aligns with the changes made in this PR.
• Upgrade package typescript from 5.6.2 to 5.6.3 #2334: Similar to the main PR, this issue focuses on upgrading TypeScript, which is part of the overall dependency management in this PR.
• Upgrade package eslint-plugin-tsdoc from 0.2.17 to 0.3.0 #2136: This issue addresses the upgrade of a linting plugin, which is relevant to the ESLint configuration updates in this PR.
• Upgrade package @testing-library/jest-dom from 5.16.5 to 6.4.5 #2015: The upgrade of Jest and related packages is mentioned, which connects to the testing improvements introduced in this PR.
• Upgrade package react-i18next from 11.18.6 to 12.3.1 #2096: This issue involves upgrading react-i18next, which is relevant to the localization files added in this PR.
• Upgrade react-bootstrap from 2.8.0 to 2.10.2 #1969: The upgrade of react-bootstrap relates to the overall dependency management and may require updates to the configurations as seen in this PR.

Possibly related PRs

• coderabbit yaml file #1991: Related as it also introduces a .coderabbit.yaml configuration file.
• develop branch - coderabbit yaml file #1997: Similar changes regarding the .coderabbit.yaml file are made here.
• Fixes: Translations Are Not Correctly Tested in Our PR Workflow  #2263: Modifications to translation handling that relate to the review settings in this PR.
• feat: Workflow changes which will label issues automatically as per #2256 #2390: This PR complements the configuration changes by ensuring the application starts correctly in Docker.
• added docker check to workflow #2414: Adds Docker checks that align with the environment setup in the main PR.
• Added GitHub PR Workflow Check: Talawa Admin app starts (No Docker) #2452: Checks for application startup without Docker, relevant to the configuration changes.
• Updated pr template with checklist #2454: Updates the pull request template to include review and test coverage checklists.
• Updated pr template for develop-postgress branch #2458: Updates the pull request template for the develop-postgres branch, connecting to overall configuration changes.

Suggested reviewers

• pranshugupta54
• varshith257

Poem

🐰 In the garden where code does bloom,
New scripts and configs dispel the gloom.
With YAML and workflows, we dance and play,
Talawa Admin shines brighter each day!
So hop along, dear friends, let's code with cheer,
For every change brings us closer, oh dear! 🐇

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[github-actions]

Congratulations on making your first PR! 🎊 If you haven't already, check out our Contributing Guidelines and PR Reporting Guidelines to ensure that you are following our guidelines for contributing and creating PR.

[coderabbitai]

Actionable comments posted: 61

🧹 Outside diff range and nitpick comments (79)

.husky/post-merge (1)

1-4: Consider enhancing the post-merge hook for better robustness.

While the basic setup is correct, consider these improvements for better reliability:

1. Check both package.json and package-lock.json
2. Add error handling for npm install

 #!/bin/sh
 . "$(dirname "$0")/_/husky.sh"
 
-git diff HEAD^ HEAD --exit-code -- ./package.json || npm install
+if git diff HEAD^ HEAD --quiet -- ./package.json ./package-lock.json; then
+  exit 0
+else
+  echo "📦 Dependencies changed. Running npm install..."
+  if npm install; then
+    echo "✅ Dependencies updated successfully"
+  else
+    echo "❌ Failed to update dependencies"
+    exit 1
+  fi
+fi

public/locales/hi/errors.json (1)

1-11: Standardize punctuation usage across messages

The error messages have inconsistent punctuation:

• Some messages end with exclamation marks
• Some have no ending punctuation
• Mixed usage of Hindi and English punctuation

Consider standardizing the punctuation style across all messages for better consistency.

scripts/custom-test-env.js (2)

4-7: Enhance JSDoc documentation with additional details.

While the documentation is clear, it could be more comprehensive with standard JSDoc tags and specific details about the TextEncoder/TextDecoder requirement.

 /**
+ * @class
+ * @extends {Environment}
  * A custom environment to set the TextEncoder and TextDecoder variables, that is required by @pdfme during testing.
  * Providing a polyfill to the environment for the same
+ * @description TextEncoder/TextDecoder are required by @pdfme for UTF-8 encoding/decoding operations during PDF generation,
+ * but may not be available in the JSDOM environment by default.
  */

---

8-16: Consider adding error handling and cleanup.

The implementation is solid but could benefit from additional robustness:

1. Add error handling for the super.setup() call
2. Consider implementing teardown() if cleanup is needed

 export default class CustomTestEnvironment extends Environment {
   async setup() {
-    await super.setup();
+    try {
+      await super.setup();
+    } catch (error) {
+      console.error('Failed to setup custom test environment:', error);
+      throw error;
+    }
     if (typeof this.global.TextEncoder === 'undefined') {
       this.global.TextEncoder = TextEncoder;
       this.global.TextDecoder = TextDecoder;
     }
   }
+
+  async teardown() {
+    // Clean up any custom globals if necessary
+    await super.teardown();
+  }
 }

.github/ISSUE_TEMPLATE/bug-report.md (1)

33-36: Improve markdown formatting.

1. Use proper heading syntax for sections
2. Format the URL as a markdown link

-**Potential internship candidates**
+## Potential internship candidates
 
 Please read this if you are planning to apply for a Palisadoes Foundation internship 
-https://github.com/PalisadoesFoundation/talawa/issues/359
+[Internship Information](https://github.com/PalisadoesFoundation/talawa/issues/359)

🧰 Tools

🪛 Markdownlint (0.35.0)

36-36: null
Bare URL used

(MD034, no-bare-urls)

---

33-33: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

scripts/__mocks__/@pdfme/generator.ts (1)

10-13: Clean up debug code and improve error messages

1. Remove the commented-out console.log statement
2. Consider providing more specific error messages to distinguish between empty template schemas and empty inputs

 if (template.schemas.length === 0 || inputs.length === 0) {
-  // console.log('pdf error: length : ', template, inputs, inputs.length);
-  throw new Error('Template or inputs cannot be empty.');
+  if (template.schemas.length === 0) {
+    throw new Error('Template schemas cannot be empty.');
+  }
+  throw new Error('Inputs array cannot be empty.');
 }

.github/workflows/codeql-codescan.yml (3)

14-20: Consider limiting workflow triggers for resource optimization

The workflow currently runs on all branches for both pull requests and pushes. This could consume unnecessary GitHub Actions minutes.

Consider limiting the triggers to specific branches:

on:
  pull_request:
    branches:
-      - '**'  
+      - 'main'
+      - 'develop'
  push:
    branches:
-      - '**'   
+      - 'main'
+      - 'develop'

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 17-17: trailing spaces

(trailing-spaces)

---

[error] 20-20: trailing spaces

(trailing-spaces)

---

31-44: Add CodeQL configuration file for enhanced analysis

The workflow would benefit from a custom CodeQL configuration file to define query suites and paths to analyze/exclude.

Would you like me to help create a codeql-config.yml file with recommended settings for your React application? This would help:

1. Define specific queries relevant to React applications
2. Exclude test files and build artifacts
3. Configure path filters for more focused analysis

🧰 Tools

🪛 yamllint (1.29.0-1)

[warning] 31-31: wrong indentation: expected 6 but found 7

(indentation)

---

[warning] 37-37: wrong indentation: expected 11 but found 10

(indentation)

---

1-11: Improve file header documentation

The header mentions reading a README.md file but doesn't specify its exact location or purpose.

Consider updating the header to be more specific:

-# Please read the README.md file in this directory that defines what should 
-# be placed in this file
+# Please read .github/workflows/README.md for workflow configuration guidelines
+# and best practices for GitHub Actions in this repository.

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 6-6: trailing spaces

(trailing-spaces)

scripts/__mocks__/@pdfme/generator.test.ts (1)

21-46: Refactor test data setup for better maintainability.

The test cases have duplicated template and input definitions. Consider extracting these into reusable fixtures.

Here's a suggested refactor:

+ const createTemplate = (schemas: any[] = []) => ({ schemas }) as Template;
+ const createInputs = (data: Record<string, string>[] = []) => data;
+
   it('should throw an error when template is empty', async () => {
-    const emptyTemplate = { schemas: [] } as Template;
-    const validInputs = [{ field1: 'value1' }];
+    const emptyTemplate = createTemplate();
+    const validInputs = createInputs([{ field1: 'value1' }]);

     await expect(
       generate({ template: emptyTemplate, inputs: validInputs }),
     ).rejects.toThrow('Template or inputs cannot be empty.');
   });

   it('should throw an error when inputs are empty', async () => {
-    const validTemplate = { schemas: [{ name: 'field1' }] } as Template;
-    const emptyInputs: Record<string, string>[] = [];
+    const validTemplate = createTemplate([{ name: 'field1' }]);
+    const emptyInputs = createInputs();

     await expect(
       generate({ template: validTemplate, inputs: emptyInputs }),
     ).rejects.toThrow('Template or inputs cannot be empty.');
   });

   it('should throw an error when both template and inputs are empty', async () => {
-    const emptyTemplate = { schemas: [] } as Template;
-    const emptyInputs: Record<string, string>[] = [];
+    const emptyTemplate = createTemplate();
+    const emptyInputs = createInputs();

     await expect(
       generate({ template: emptyTemplate, inputs: emptyInputs }),
     ).rejects.toThrow('Template or inputs cannot be empty.');
   });

.github/pull_request_template.md (1)

22-37: Enhance section prompts for better clarity

The new sections are good additions, but could be more specific:

1. Issue number section could specify the format (e.g., "Adding new page - posts #123")
2. Documentation section could provide specific documentation paths

Consider applying these enhancements:

 **Issue Number:**

-Fixes #<!--Add related issue number here.-->
+Fixes # <!-- Add issue number (e.g., #123) -->

 **If relevant, did you update the documentation?**

-<!--Add link to Talawa-Docs.-->
+<!--
+Add link to updated documentation in:
+- Talawa-Docs repository
+- API documentation
+- Code comments
+-->

.github/workflows/stale.yml (2)

18-21: Fix trailing whitespace

Remove trailing spaces to improve code formatting.

 permissions:
   issues: write
-  pull-requests: write  
-  
+  pull-requests: write

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 20-20: trailing spaces

(trailing-spaces)

---

[error] 21-21: trailing spaces

(trailing-spaces)

---

27-43: Consider optimizing stale configuration parameters

The configuration is generally good, but consider these suggestions for optimization:

1. The 180-day close period (days-before-close: 180) is quite long. Consider reducing it to 90 days to maintain a more active repository.
2. The operations-per-run: 30 limit might be too low if you have many issues/PRs. Consider increasing it based on your repository's size.

The messages are well-written and provide clear guidance to contributors.

       days-before-stale: 10
-      days-before-close: 180
+      days-before-close: 90
       remove-stale-when-updated: true
       exempt-all-milestones: true
       exempt-pr-labels: 'wip'
       exempt-issue-labels: 'wip'
-      operations-per-run: 30
+      operations-per-run: 100

.github/workflows/check-tsdoc.js (3)

1-1: Remove redundant comment

The comment is unnecessary as the import statement clearly shows we're using the promises API.

-import fs from 'fs/promises'; // Import fs.promises for async operations
+import fs from 'fs/promises';

---

4-11: Document why files are being skipped

Add a comment explaining the rationale for excluding these specific files from TSDoc validation.

-// List of files to skip
+// Files excluded from TSDoc validation because [reason]
 const filesToSkip = [

---

14-35: Consider improvements to file traversal logic

A few suggestions to enhance robustness and maintainability:

1. Use path.normalize() for consistent path separators across platforms
2. Consider implementing batch processing for large directories
3. Consider using a logger instead of console.error for better error tracking

 async function findTsxFiles(dir) {
   let results = [];
   try {
     const list = await fs.readdir(dir);
     for (const file of list) {
-      const filePath = path.join(dir, file);
+      const filePath = path.normalize(path.join(dir, file));
       const stat = await fs.stat(filePath);
       if (stat.isDirectory()) {
         results = results.concat(await findTsxFiles(filePath));
       } else if (
         filePath.endsWith('.tsx') &&
         !filePath.endsWith('.test.tsx') &&
-        !filesToSkip.includes(path.relative(dir, filePath))
+        !filesToSkip.includes(path.basename(filePath))
       ) {
         results.push(filePath);
       }
     }
   } catch (err) {
-    console.error(`Error reading directory ${dir}: ${err.message}`);
+    throw new Error(`Failed to read directory ${dir}: ${err.message}`);
   }
   return results;
 }

.github/workflows/push.yml (3)

19-20: Fix YAML indentation

The env section should be indented with 2 spaces to maintain consistency with YAML standards.

 env:
-    CODECOV_UNIQUE_NAME: CODECOV_UNIQUE_NAME-${{ github.run_id }}-${{ github.run_number }}
+  CODECOV_UNIQUE_NAME: CODECOV_UNIQUE_NAME-${{ github.run_id }}-${{ github.run_number }}

🧰 Tools

🪛 yamllint (1.29.0-1)

[warning] 20-20: wrong indentation: expected 2 but found 4

(indentation)

---

42-45: Enhance cache key strategy

Include Node.js version in the cache key to prevent potential issues when switching Node versions.

         with:
           path: |
             ~/.npm
             node_modules
-          key: ${{ runner.os }}-code-coverage-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
+          key: ${{ runner.os }}-code-coverage-${{ env.cache-name }}-node-${{ matrix.node-version }}-${{ hashFiles('**/package-lock.json') }}

---

54-61: Consider test command and Codecov configuration improvements

A few suggestions for the test and coverage steps:

1. The test command could be more explicit about its coverage configuration
2. Consider enabling fail_ci_if_error for Codecov to ensure coverage data is properly uploaded

-      - run: npm run test -- --watchAll=false --coverage
+      - name: Run tests with coverage
+        run: npm run test -- --watchAll=false --coverage --coverageReporters=lcov --coverageDirectory=coverage
       - name: Present and upload coverage to Codecov as ${{env.CODECOV_UNIQUE_NAME}}
         uses: codecov/codecov-action@v4
         with:
           token: ${{ secrets.CODECOV_TOKEN }}
           verbose: true
-          fail_ci_if_error: false
+          fail_ci_if_error: true
           name: '${{env.CODECOV_UNIQUE_NAME}}'

jest.config.js (1)

60-65: Consider increasing coverage thresholds.

The current coverage thresholds of 20% for lines and statements are quite low and might not provide adequate test coverage. This is particularly important given that this PR aims to fix failing tests.

Consider gradually increasing these thresholds to industry-standard levels (70-80%) to ensure better code quality and catch potential issues early.

scripts/githooks/check-localstorage-usage.js (2)

51-56: Consider moving file exclusions to configuration

The hardcoded file exclusions would be better maintained in a configuration file, making it easier to update without modifying the script.

Consider creating a .localstorage-checkrc.json file:

{
  "excludeFiles": [
    "check-localstorage-usage.js",
    "useLocalstorage.test.ts",
    "useLocalstorage.ts"
  ]
}

---

1-1: Add documentation for the skip comment feature

The script supports a special comment to skip checks, but this feature isn't documented. Consider adding a README.md file in the scripts/githooks directory.

Example documentation:

# LocalStorage Usage Check

This script enforces the use of custom localStorage hooks instead of direct localStorage access.

## Skip Checks

To skip the localStorage check for a specific file, add the following comment:

```javascript
// SKIP_LOCALSTORAGE_CHECK

</blockquote></details>
<details>
<summary>.github/workflows/issue.yml (4)</summary><blockquote>

`6-7`: **Add the specific path to the referenced README.md**

The header comment mentions a README.md file but doesn't specify its exact location. Consider updating the comment to include the full path for better clarity.

```diff
-# Please read the README.md file in this directory that defines what should 
+# Please read .github/workflows/README.md that defines what should 

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 6-6: trailing spaces

(trailing-spaces)

---

42-55: Refactor label automation logic for better maintainability

The current implementation has duplicated code and complex reduce operations. Consider refactoring for better readability and maintainability.

-            if(labels.data.reduce((a, c)=>a||["dependencies"].includes(c.name), false))
-              await github.rest.issues.addLabels({
-                owner: context.repo.owner,
-                repo: context.repo.repo,
-                issue_number: context.issue.number,
-                labels: ["good first issue", "security"]
-              });
-            else if(labels.data.reduce((a, c)=>a||["security", "ui/ux"].includes(c.name), false))
-              await github.rest.issues.addLabels({
-                owner: context.repo.owner,
-                repo: context.repo.repo,
-                issue_number: context.issue.number,
-                labels: ["good first issue"]
-              });
+            const labelNames = labels.data.map(label => label.name);
+            const labelsToAdd = new Set(["good first issue"]);
+            
+            if (labelNames.includes("dependencies")) {
+              labelsToAdd.add("security");
+            } else if (labelNames.some(name => ["security", "ui/ux"].includes(name))) {
+              // only add "good first issue" which is already in the set
+            }
+            
+            if (labelsToAdd.size > 0) {
+              await github.rest.issues.addLabels({
+                ...apiParams,
+                labels: Array.from(labelsToAdd)
+              });
+            }

---

62-65: Consider externalizing the greeting message

Long strings in workflow files can be hard to maintain. Consider moving the greeting message to a separate file.

       - uses: actions/first-interaction@v1
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          issue-message: "Congratulations on making your first Issue! :confetti_ball: If you haven't already, check out our [Contributing Guidelines](https://github.com/PalisadoesFoundation/talawa-admin/blob/develop/CONTRIBUTING.md) and [Issue Reporting Guidelines](https://github.com/PalisadoesFoundation/talawa-admin/blob/develop/ISSUE_GUIDELINES.md) to ensure that you are following our guidelines for contributing and making issues."
+          issue-message: ${{ vars.FIRST_ISSUE_GREETING }}

Create a repository variable FIRST_ISSUE_GREETING with the message content for better maintainability.

---

6-6: Fix formatting issues

The static analysis tool identified several formatting issues:

1. Remove trailing spaces
2. Fix indentation (expected 4 spaces)
3. Remove extra blank lines at the end of file

-# Please read the README.md file in this directory that defines what should 
+# Please read the README.md file in this directory that defines what should
       types: ['opened']
-

Also applies to: 15-15, 66-66

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 6-6: trailing spaces

(trailing-spaces)

.github/workflows/talawa_admin_md_mdx_format_adjuster.py (3)

3-14: Enhance documentation with usage examples and MDX explanation

The docstring is well-structured but could be more helpful by including:

• Example usage of the script
• Brief explanation of what MDX is and why escaping is necessary
• Sample input/output to demonstrate the transformation

 """
 Script to make Markdown files MDX compatible.

 This script scans Markdown files and escapes special characters (<, >, {, })
 to make them compatible with the MDX standard used in Docusaurus v3.

+Example usage:
+    python3 talawa_admin_md_mdx_format_adjuster.py --directory ./docs
+
+MDX is a format that combines Markdown with JSX, requiring special characters
+to be escaped. For example:
+    Input:  Use <Component> to render
+    Output: Use \<Component\> to render
+
 This script complies with:
     1) Pylint
     2) Pydocstyle
     3) Pycodestyle
     4) Flake8
 """

---

19-44: Optimize regex patterns and add test coverage

The function logic is correct but could be optimized:

1. Compile regex patterns once at module level for better performance
2. Add test cases to verify edge cases (e.g., mixed escaped/unescaped characters)

+# Compile patterns once at module level
+_REGEX_PATTERNS = {
+    "<": re.compile(r"(?<!\\)<"),
+    ">": re.compile(r"(?<!\\)>"),
+    "{": re.compile(r"(?<!\\){"),
+    "}": re.compile(r"(?<!\\)}")
+}

 def escape_mdx_characters(text):
     """
     Escape special characters in a text string for MDX compatibility.
     Avoids escaping already escaped characters.

     Args:
         text: A string containing the text to be processed.

     Returns:
         A string with special characters (<, >, {, }) escaped, avoiding
         double escaping.
     """
-    # Regular expressions to find unescaped special characters
-    patterns = {
-        "<": r"(?<!\\)<",
-        ">": r"(?<!\\)>",
-        "{": r"(?<!\\){",
-        "}": r"(?<!\\)}"
-    }

     # Replace unescaped special characters
-    for char, pattern in patterns.items():
-        text = re.sub(pattern, f"\\{char}", text)
+    for char, pattern in _REGEX_PATTERNS.items():
+        text = pattern.sub(f"\\{char}", text)

     return text

Would you like me to generate unit tests to cover edge cases?

---

66-96: Enhance CLI with additional options and validation

The main function could be improved with better directory validation and additional CLI options.

 def main():
     """
     Main function to process all Markdown files in a given directory.

     Scans for all Markdown files in the specified directory and processes each
     one for MDX compatibility.

     Args:
         None

     Returns:
         None
     """
     parser = argparse.ArgumentParser(description="Make Markdown files MDX compatible.")
     parser.add_argument(
         "--directory",
         type=str,
         required=True,
         help="Directory containing Markdown files to process."
     )
+    parser.add_argument(
+        "--recursive",
+        action="store_true",
+        help="Recursively process subdirectories"
+    )
+    parser.add_argument(
+        "--dry-run",
+        action="store_true",
+        help="Show which files would be modified without making changes"
+    )
+    parser.add_argument(
+        "--verbose",
+        action="store_true",
+        help="Enable verbose output"
+    )

     args = parser.parse_args()

+    # Validate directory
+    if not os.path.isdir(args.directory):
+        parser.error(f"Directory not found: {args.directory}")
+
+    # Configure logging
+    log_level = logging.DEBUG if args.verbose else logging.INFO
+    logging.basicConfig(level=log_level, format='%(message)s')

     # Process each Markdown file in the directory
-    for root, _, files in os.walk(args.directory):
+    if args.recursive:
+        walker = os.walk(args.directory)
+    else:
+        walker = [(args.directory, [], os.listdir(args.directory))]
+
+    for root, _, files in walker:
         for file in files:
             if file.lower().endswith(".md"):
-                process_file(os.path.join(root, file))
+                filepath = os.path.join(root, file)
+                if args.dry_run:
+                    logging.info("Would process: %s", filepath)
+                else:
+                    process_file(filepath)

public/locales/sp/common.json (3)

1-1: Consider relocating the file to the correct language code folder

The folder is named 'sp', but the ISO language code for Spanish is 'es'. Consider moving this file to public/locales/es/common.json to follow international standards.

---

10-12: Maintain consistent casing for role names

The role names use inconsistent casing. Consider using consistent casing for all role names:

-  "admin": "ADMIN",
-  "user": "USER",
-  "superAdmin": "SUPERADMIN",
+  "admin": "Administrador",
+  "user": "Usuario",
+  "superAdmin": "Superadministrador",

---

87-88: Review and improve session warning translations

The session warning messages could be improved for more natural Spanish:

-  "sessionWarning": "Su sesión expirará pronto debido a la inactividad. Por favor, interactúe con la página para extender su sesión.",
-  "sessionLogOut": "Su sesión ha expirado debido a la inactividad. Por favor, inicie sesión nuevamente para continuar.",
+  "sessionWarning": "Su sesión expirará pronto por inactividad. Por favor, interactúe con la página para mantener la sesión activa.",
+  "sessionLogOut": "Su sesión ha expirado por inactividad. Por favor, vuelva a iniciar sesión para continuar.",

.github/workflows/pull-request-target.yml (2)

22-68: Fix formatting issues in the PR review policy message

The message content is comprehensive, but there are some formatting inconsistencies:

1. Line 67 ends with an incomplete sentence: "Read the CONTRIBUTING.md file make"
2. Inconsistent list numbering (mixing 1. and 1.)

-            1. PRs with issues not assigned to you will be closed by the reviewer
-            1. Fix the first comment in the PR so that each issue listed automatically closes
+            1. PRs with issues not assigned to you will be closed by the reviewer
+            2. Fix the first comment in the PR so that each issue listed automatically closes

-            1. :dart: Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
-            2. Read the CONTRIBUTING.md file make 
+            1. :dart: Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
+            2. Read the CONTRIBUTING.md file for complete guidelines.

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 36-36: trailing spaces

(trailing-spaces)

---

[error] 42-42: trailing spaces

(trailing-spaces)

---

[error] 67-67: trailing spaces

(trailing-spaces)

---

6-6: Remove trailing spaces

The following lines contain trailing spaces that should be removed:

• Line 6: "Please read the README.md file in this directory that defines what should "
• Line 13: "on: "
• Line 15: " pull_request_target:"
• Line 36: " 3. Merge conflicts "
• Line 42: " Do not assign reviewers. Our Queue Monitors will review your PR and assign them. "
• Line 67: " 2. Read the CONTRIBUTING.md file make "

Also applies to: 13-13, 15-15, 36-36, 42-42, 67-67

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 6-6: trailing spaces

(trailing-spaces)

README.md (1)

53-56: Fix heading formatting

There are extra spaces after the hash symbol in the "Videos" heading.

-#  Videos
+# Videos

🧰 Tools

🪛 Markdownlint (0.35.0)

53-53: null
Multiple spaces after hash on atx style heading

(MD019, no-multiple-space-atx)

🪛 LanguageTool

[uncategorized] ~56-~56: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...)" videos are extremely helpful for new open source contributors.

(EN_COMPOUND_ADJECTIVE_INTERNAL)

PR_GUIDELINES.md (4)

1-5: Improve readability of the introduction section

Consider these refinements to enhance clarity and professionalism:

# Pull Request Guidelines

-:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
+:tada: Thank you for taking the time to contribute! :tada:

-In order to give everyone a chance to submit a pull request and contribute to the Talawa project, we have put restrictions in place. This section outlines the guidelines that should be imposed upon pull requests in the Talawa project.
+To ensure fair contribution opportunities in the Talawa project, we have established guidelines for pull requests. These guidelines help maintain quality and consistency across contributions.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~2-~2: Loose punctuation mark.
Context: # Pull Request Guidelines 👍🎉 First off, thanks for taking t...

(UNLIKELY_OPENING_PUNCTUATION)

---

[style] ~4-~4: Consider a shorter alternative to avoid wordiness.
Context: ...ing the time to contribute! 🎉👍 In order to give everyone a chance to submit a pull...

(IN_ORDER_TO_PREMIUM)

---

31-42: Add language specifiers to code blocks

Add language specifiers to the code blocks for proper syntax highlighting.

-```
+```bash
npm run lint:fix
npm run format:fix

- +bash
npm run lint:check
npm run format:check

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 Markdownlint (0.35.0)</summary>

31-31: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

39-39: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

</details>

</details>

---

`54-69`: **Improve organization of pull request rules**

The guidelines would be more digestible if organized into logical groups with clear subsection headers.

Consider reorganizing the content into these subsections:

1. Branch and PR Requirements
   - PR against develop branch
   - No draft PRs
   - One PR at a time per contributor
   
2. Code Quality Requirements
   - Passing tests
   - Code quality standards
   - Borrowed code disclosure
   
3. Communication Guidelines
   - PR template usage
   - Response time expectations
   - @mention policy

This organization would make it easier for contributors to find and follow specific guidelines.

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~56-~56: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...o be closed. The quality of our code is very important to us. Therefore we make experienced ma...

(EN_WEAK_ADJECTIVE)

---

[uncategorized] ~56-~56: A comma may be missing after the conjunctive/linking adverb ‘Therefore’.
Context: ...ty of our code is very important to us. Therefore we make experienced maintainers of our ...

(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...check if all tests are passing; if not, fix the issues and then create a pull reque...

(FIX_RESOLVE)

---

[style] ~64-~64: This expression is wordy and overused. Consider replacing it with a more concise and formal alternative.
Context: ...wer your questions, but we'll get to it sooner or later. @mentioning someone just adds to the p...

(SOONER_OR_LATER)

---

[uncategorized] ~64-~64: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...adds to the pile of notifications we get and it won't make us look at your issue fas...

(COMMA_COMPOUND_SENTENCE)

---

[style] ~65-~65: Consider shortening or rephrasing this to strengthen your wording.
Context: ...ue faster. 1. Do not force push. If you make changes to your pull request, please simply add a ...

(MAKE_CHANGES)

</details>

</details>

---

`46-47`: **Add example for test documentation**

Consider adding an example template for documenting manual testing steps when automated tests aren't possible.

```markdown
Example format for manual testing documentation:
1. Test Scenario: [Describe what you're testing]
2. Prerequisites: [List required setup]
3. Test Steps:
   - Step 1: [Action]
   - Step 2: [Action]
4. Expected Results: [What should happen]
5. Actual Results: [What actually happened]

🧰 Tools

🪛 LanguageTool

[style] ~46-~46: Style-wise, it’s not ideal to insert an adverb (‘manually’) in the middle of an infinitive construction (‘to test’). Try moving the adverb to avoid split infinitives.
Context: ..., you'll need to tell us what steps you followed to manually test your changes. 1. Please read our [CONTRIBUTING.md](C...

(SPLIT_INFINITIVE)

CODE_STYLE.md (7)

5-7: Consider consolidating redundant statements

Lines 5 and 7 both emphasize following the code style. Consider merging these into a single, stronger statement.

-The code style must be strictly adhered to, to ensure that there is consistency throughout the contributions made to Talawa-Admin
-
-code style should not be changed and must be followed.
+The code style must be strictly adhered to and cannot be modified, ensuring consistency throughout all contributions to Talawa-Admin.

---

26-38: Consider adding version information for tech stack

The tech stack section would be more helpful if it included specific version requirements or version ranges for each technology.

-Typescript
-React.js 
-CSS module
-React bootstrap
-Material UI
-GraphQL
-Jest & React Testing Library for testing
+TypeScript ^4.0.0
+React.js ^18.0.0
+CSS Modules
+React Bootstrap ^5.3.0
+Material UI ^5.0.0
+GraphQL ^16.0.0
+Jest ^29.0.0 & React Testing Library ^14.0.0

---

42-44: Add examples for component structure

The component structure section would benefit from practical examples demonstrating the proper use of functional components and hooks.

Consider adding an example like:

// ✅ Good Example
import React, { useState, useEffect } from 'react';

const UserProfile: React.FC = () => {
  const [userData, setUserData] = useState(null);

  useEffect(() => {
    // Fetch user data
  }, []);

  return (
    // JSX
  );
};

export default UserProfile;

---

58-69: Add language specifiers to code blocks

Code blocks should specify the language for proper syntax highlighting.

-```
+```jsx
 <div className="myCustomClass">...</div>

🧰 Tools

🪛 Markdownlint (0.35.0)

58-58: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

65-65: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

127-137: Fix directory structure indentation

The directory structure section has inconsistent indentation levels.

Use consistent 2-space indentation for all nested items in the directory structure.

🧰 Tools

🪛 Markdownlint (0.35.0)

128-128: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

129-129: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

130-130: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

131-131: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

132-132: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

133-133: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

134-134: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

135-135: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

136-136: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

137-137: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

🪛 LanguageTool

[style] ~127-~127: Consider removing “of” to be more concise
Context: ...tories of src assets - This houses all of the static assets used in the project - `...

(ALL_OF_THE)

---

[style] ~128-~128: Consider removing “of” to be more concise
Context: ... in the project - css - This houses all of the css files used in the project - `imag...

(ALL_OF_THE)

---

[style] ~129-~129: Consider removing “of” to be more concise
Context: ... the project - images - This houses all of the images used in the project - scss -...

(ALL_OF_THE)

---

[style] ~130-~130: Consider removing “of” to be more concise
Context: ...in the project - scss - This houses all of the scss files used in the project - `c...

(ALL_OF_THE)

---

[grammar] ~134-~134: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ...rms - _talawa.scss - Partial Sass file for Talawa - _utilities.scss - Pa...

(HE_VERB_AGR)

---

[grammar] ~135-~135: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ... - _utilities.scss - Partial Sass file for utilities - _variables.scss -...

(HE_VERB_AGR)

---

[grammar] ~136-~136: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ... - _variables.scss - Partial Sass file for variables - app.scss - Main S...

(HE_VERB_AGR)

---

165-165: Use hyphenation for compound adjective

"Third party" should be hyphenated when used as a compound adjective.

-- Third party imports
+- Third-party imports

🧰 Tools

🪛 Markdownlint (0.35.0)

165-165: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

🪛 LanguageTool

[uncategorized] ~165-~165: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...following order: - React imports - Third party imports - Local imports If there is...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

232-234: Maintain consistent capitalization of "Sass"

"Sass" is a proper noun and should always be capitalized consistently.

-According to naming convention the file name of the partial Sass files should start with an underscore `_` and end with `.scss`, these partial sass files are not meant to be compiled directly, they are meant to be imported into another sass file.
+According to naming convention the file name of the partial Sass files should start with an underscore `_` and end with `.scss`, these partial Sass files are not meant to be compiled directly, they are meant to be imported into another Sass file.

.github/workflows/pull-request.yml (2)

132-134: Enhance error message for unauthorized file changes

The current error message could be more helpful by explaining the process for getting authorization.

- echo "$file is unauthorized to change/delete"
+ echo "⛔ $file is unauthorized to change/delete. Please refer to CONTRIBUTING.md for the process of getting authorization for sensitive file changes."

---

35-36: Add caching for Node.js dependencies

Consider adding caching to improve workflow performance and reduce installation time.

+ - name: Cache Node.js dependencies
+   uses: actions/cache@v3
+   with:
+     path: ~/.npm
+     key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+     restore-keys: |
+       ${{ runner.os }}-node-
+
  - name: Install Dependencies
    run: npm install

CONTRIBUTING.md (6)

27-27: Consider adding "please" for politeness

Consider revising to: "Please let us know immediately if you have unacceptable experiences in this area."

🧰 Tools

🪛 LanguageTool

[style] ~27-~27: This expression usually appears with a “please” in front of it.
Context: ...DUCT.md) to understand what this means. Let us know immediately if you have unacceptable ex...

(INSERT_PLEASE)

---

34-34: Add hyphen in compound adjective

Revise "open source contributors" to "open-source contributors" as it's used as a compound adjective.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~34-~34: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...)" videos are extremely helpful for new open source contributors. ## Ways to Contribute I...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

62-62: Fix grammatical and capitalization issues

Several improvements needed:

1. Line 62: Add "the" - "is the best resource"
2. Lines 75, 77, 178: Capitalize "Slack" as it's a proper noun

Also applies to: 75-75, 77-77, 178-178

🧰 Tools

🪛 LanguageTool

[grammar] ~62-~62: A determiner may be missing.
Context: ...l Request guidelines](PR_GUIDELINES.md) is best resource to follow to start working on ...

(THE_SUPERLATIVE)

---

104-144: Add language specifications to code blocks

Add language specifications to all fenced code blocks for proper syntax highlighting. For example:

-```
+```bash
npm install

🧰 Tools

🪛 Markdownlint (0.35.0)

104-104: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

113-113: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

128-128: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

139-139: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

143-143: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🪛 LanguageTool

[grammar] ~135-~135: The operating system from Apple is written “macOS”.
Context: ...r packages can be found for Windows and MacOS. 6. The currently acceptable c...

(MAC_OS)

---

135-135: Fix technical writing issues

1. Line 135: Change "MacOS" to "macOS"
2. Line 165: Add missing articles and comma: "Here, the branch name must be the name of the branch"

Also applies to: 165-165

🧰 Tools

🪛 LanguageTool

[grammar] ~135-~135: The operating system from Apple is written “macOS”.
Context: ...r packages can be found for Windows and MacOS. 6. The currently acceptable c...

(MAC_OS)

---

158-161: Fix empty image links

Remove the empty markdown links after the images or provide proper URLs:

-[![Code-cov-token.jpg](/public/images/codecov/Code-cov-token.jpg)]()
+![Code-cov-token.jpg](/public/images/codecov/Code-cov-token.jpg)

🧰 Tools

🪛 Markdownlint (0.35.0)

158-158: null
No empty links

(MD042, no-empty-links)

---

159-159: null
No empty links

(MD042, no-empty-links)

---

161-161: null
No empty links

(MD042, no-empty-links)

INSTALLATION.md (3)

142-144: Add language specifiers to code blocks

Code blocks should specify their language for proper syntax highlighting. For example:

-```
+```bash
 npm install

- +bash
npm run setup

-```
+```bash
cp .env.example .env

Also applies to: 154-156, 164-166

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 Markdownlint (0.35.0)</summary>

142-142: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

</details>

</details>

---

`189-202`: **Standardize URL examples and add validation steps**

The URL examples use inconsistent formats and lack validation steps. Consider:
1. Using consistent placeholder formats (e.g., `{API_HOST}` instead of mixing `API-IP-ADDRESS` and `YOUR-REMOTE-ADDRESS`)
2. Adding steps to validate the configuration

```diff
-REACT_APP_TALAWA_URL="http://API-IP-ADRESS:4000/graphql/"
+REACT_APP_TALAWA_URL="http://{API_HOST}:4000/graphql/"

Also, consider adding a section on how to validate the configuration, such as checking API connectivity.

🧰 Tools

🪛 Markdownlint (0.35.0)

194-194: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

200-200: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

67-68: Fix grammatical and spelling issues

Several language issues need to be addressed:

1. "setup" is incorrectly used as a verb (should be "set up")
2. Inconsistent spelling of "macOS" (currently written as "MacOS")
3. Missing commas in compound sentences

Apply these corrections:

-navigate to the folder where you want to setup the repository
+navigate to the folder where you want to set up the repository

-`cmd` (Windows) or `terminal` (Linux or MacOS)
+`cmd` (Windows) or `terminal` (Linux or macOS)

-You may not want to setup reCAPTCHA
+You may not want to set up reCAPTCHA

Also applies to: 102-102, 119-119, 228-232

🧰 Tools

🪛 LanguageTool

[grammar] ~67-~67: The word “setup” is a noun. The verb is spelled with a space.
Context: ...avigate to the folder where you want to setup the repository. 2. Open a cmd (Window...

(NOUN_VERB_CONFUSION)

---

[grammar] ~68-~68: The operating system from Apple is written “macOS”.
Context: ...cmd (Windows) or terminal (Linux or MacOS) session in this folder. 1. An easy ...

(MAC_OS)

.github/workflows/eslint_disable_check.py (2)

61-61: Rename unused variable dirs to _ or _dirs

The variable dirs in the loop is not used. Renaming it to _ or _dirs indicates that it's intentionally unused and adheres to Python conventions.

Apply this diff to rename the variable:

-for root, dirs, files in os.walk(os.path.join(directory, 'src')):
+for root, _dirs, files in os.walk(os.path.join(directory, 'src')):

🧰 Tools

🪛 Ruff (0.7.0)

61-61: Loop control variable dirs not used within loop body

Rename unused dirs to _dirs

(B007)

---

76-81: Clarify the return value in arg_parser_resolver docstring

The docstring mentions returning result, but the function actually returns args. Updating the return description improves clarity.

Apply this diff to correct the docstring:

     """
     Resolve the CLI arguments provided by the user.

     Returns:
-        result: Parsed argument object
+        argparse.Namespace: Parsed argument object
     """

setup.ts (5)

72-76: Add a maximum retry limit when checking the connection.

The loop that checks the connection to the Talawa API endpoint could potentially become infinite if the connection cannot be established. This might frustrate users.

Introduce a retry limit to prevent an infinite loop:

 let isConnected = false,
   endpoint = '';
+ let retryCount = 0;
+ const maxRetries = 5;

 while (!isConnected) {
   endpoint = await askForTalawaApiUrl();
   const url = new URL(endpoint);
   isConnected = await checkConnection(url.origin);
+  retryCount++;
+  if (retryCount >= maxRetries && !isConnected) {
+    console.error('Maximum retries reached. Please check your network connection.');
+    process.exit(1);
+  }
 }

---

99-105: Confirm default value for ReCAPTCHA setup.

The prompt for setting up ReCAPTCHA defaults to true. Considering not all users may have ReCAPTCHA keys, consider defaulting to false to prevent confusion.

 const { shouldUseRecaptcha } = await inquirer.prompt({
   type: 'confirm',
   name: 'shouldUseRecaptcha',
   message: 'Would you like to set up ReCAPTCHA?',
-  default: true,
+  default: false,
 });

---

140-145: Improve validation message for ReCAPTCHA site key input.

The validation message Invalid reCAPTCHA site key. Please try again. may not provide enough information to the user about why the input is invalid.

Consider providing more detailed feedback:

 return 'Invalid ReCAPTCHA site key. It should be a non-empty string. Please try again.';

---

163-169: Review default setting for logging errors.

The prompt for logging compile-time and runtime errors defaults to true. Depending on the typical user preference, consider defaulting to false if logging is optional.

 const { shouldLogErrors } = await inquirer.prompt({
   type: 'confirm',
   name: 'shouldLogErrors',
   message:
     'Would you like to log compile-time and runtime errors in the console?',
-  default: true,
+  default: false,
 });

---

180-182: Enhance user experience with final message.

Consider providing next steps or additional information after the setup is complete to improve user onboarding.

 console.log(
   '\nCongratulations! Talawa Admin has been successfully set up! 🥂🎉',
+  '\nYou can now start the development server by running `npm start`.',
 );

.github/workflows/countline.py (14)

23-24: Provide the missing commands in the docstring's 'NOTE' section

The docstring mentions "Run these commands from the CLI to ensure the code is compliant for all your pull requests," but the specific commands are not included. Including the exact commands (e.g., pylint, pydocstyle, pycodestyle, flake8) will help contributors ensure compliance with the coding standards.

---

35-56: Enhance filename validation logic

Currently, _valid_filename() checks for substrings ".test." and ".spec." in the file path to invalidate filenames. This might miss files that have these patterns at the start or end of the filename. Consider using os.path.basename() and regex patterns to improve filename validation.

Apply this diff to enhance the validation:

-def _valid_filename(filepath):
+def _valid_filename(filepath):
+    """Determine whether filepath has a valid filename.

    Args:
        filepath: Filepath to check

    Returns:
        result: True if valid

    """
    invalid_patterns = [r'\.test\.', r'\.spec\.']
    filename = os.path.basename(filepath).lower()
    for pattern in invalid_patterns:
        if re.search(pattern, filename):
            return False
    return True

---

68-79: Consider specifying valid extensions instead of invalid ones

In _valid_extension(), specifying invalid extensions may lead to new file types being unintentionally processed. It's safer to define a list of valid code file extensions to ensure only intended files are analyzed.

Apply this diff:

-def _valid_extension(filepath):
-    """Determine whether filepath has the correct extension.
-
-    Args:
-        filepath: Filepath to check
-
-    Returns:
-        result: True if valid
-
-    """
-    invalid_extensions = [".css", ".jpg", ".png", ".jpeg"]
-    result = True
-    for invalid_extension in invalid_extensions:
-        if filepath.lower().endswith(invalid_extension.lower()):
-            result = False
-            break
-    return result
+def _valid_extension(filepath):
+    """Determine whether filepath has a valid code file extension.

    Args:
        filepath: Filepath to check

    Returns:
        result: True if valid

    """
    valid_extensions = [".py", ".js", ".dart"]
    for valid_extension in valid_extensions:
        if filepath.lower().endswith(valid_extension.lower()):
            return True
    return False

---

114-114: Use os.path.join instead of string formatting for file paths

Using os.path.join enhances code readability and ensures compatibility across different operating systems.

Apply this diff:

-            filepath = "{}{}{}".format(os.getcwd(), os.sep, filename)
+            filepath = os.path.join(os.getcwd(), filename)

---

137-140: Correct misleading comment in _filepaths_in_directories function

The comment indicates that files are read and lines are counted, but the function only collects file paths.

Apply this diff:

             for root, _, files in os.walk(directory, topdown=False):
                 for name in files:
-                    # Read each file and count the lines found
+                    # Collect file paths
                     result.append(os.path.join(root, name))

---

145-195: Simplify help strings in argparse arguments

Using triple-quoted strings and backslashes is unnecessary in the help messages. Simplify to single-line strings for clarity.

Apply this diff:

         parser.add_argument(
             "--exclude_files",
             type=str,
             required=False,
             nargs="*",
             default=None,
             const=None,
-            help="""An optional space separated list of \
-files to exclude from the analysis.""",
+            help="An optional space-separated list of files to exclude from the analysis.",
         )
         parser.add_argument(
             "--exclude_directories",
             type=str,
             required=False,
             nargs="*",
             default=None,
             const=None,
-            help="""An optional space separated list of \
-directories to exclude from the analysis.""",
+            help="An optional space-separated list of directories to exclude from the analysis.",
         )

---

198-198: Update main function docstring to reflect actual functionality

The docstring states "Analyze dart files," but the script is designed to analyze code files in general. Update the docstring for accuracy.

Apply this diff:

 def main():
-    """Analyze dart files.
+    """Analyze code files for excessive line lengths.

---

213-214: Initialize errors_found as an integer for consistency with its usage

errors_found is used in a boolean context and later as an integer (file_count). To avoid confusion, consider renaming or separating the counter from the boolean flag.

Apply this diff:

-    errors_found = False
-    file_count = 0
+    file_count = 0

And update relevant conditions:

-    if errors_found:
+    if file_count > 0:

---

225-230: Handle missing directories gracefully

When the directories lib, src, or test do not exist, the script may fail. Consider adding a check to ensure directories exist before processing.

Apply this diff:

 for directory in directories:
+    if not os.path.exists(directory):
+        continue
     for root, _, files in os.walk(directory, topdown=False):

---

243-245: Exclude venv or virtual environment directories

Virtual environment directories can contain many files that are not relevant to the analysis. Consider excluding them to improve performance.

Apply this diff:

     # Skip /node_modules/ sub directories
     if "{0}node_modules{0}".format(os.sep) in filepath:
         continue
+    if "{0}venv{0}".format(os.sep) in filepath:
+        continue

---

255-255: Use 'utf-8' encoding when opening files

Using 'utf-8' encoding ensures compatibility with most text files and is the standard encoding for modern text. Handling encoding errors prevents unexpected crashes.

Apply this diff:

-            with open(filepath, encoding="latin-1") as code:
+            with open(filepath, encoding="utf-8", errors="ignore") as code:

---

267-267: Fix the typo in the comment

There's a typo in the comment: "voilated" should be "violated".

Apply this diff:

-    # If the line rule is voilated then the value is changed to 1
+    # If the line rule is violated, increment the error count

---

281-281: Simplify the conditional check

The expression if bool(errors_found) is True: can be simplified to if errors_found: for readability.

Apply this diff:

-    if bool(errors_found) is True:
+    if errors_found:

---

291-294: No need for else after sys.exit

After calling sys.exit(1), the program terminates, so the else block is unnecessary.

Apply this diff:

         sys.exit(1)
-    else:
-        sys.exit(0)
+    sys.exit(0)

schema.graphql (1)

779-779: Inconsistent type for organizationId field in OrganizationCustomField

The organizationId field is defined as String! at lines 779 and 786, whereas other ID fields use the ID! type. For consistency and to leverage GraphQL's built-in ID type, it's recommended to use ID! for all identifier fields.

Please update the field type to ID!.

-  organizationId: String!
+  organizationId: ID!

-  organizationId: String!
+  organizationId: ID!

Also applies to: 786-786

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between ff25183 and 9b9321d.

⛔ Files ignored due to path filters (75)

• package-lock.json is excluded by !**/package-lock.json
• public/favicon.ico is excluded by !**/*.ico
• public/favicon_palisadoes.ico is excluded by !**/*.ico
• public/images/logo512.png is excluded by !**/*.png
• public/images/svg/angleDown.svg is excluded by !**/*.svg
• public/images/svg/arrow-left.svg is excluded by !**/*.svg
• public/images/svg/arrow-right.svg is excluded by !**/*.svg
• public/images/svg/attendees.svg is excluded by !**/*.svg
• public/images/svg/feedback.svg is excluded by !**/*.svg
• public/images/svg/profiledefault.svg is excluded by !**/*.svg
• public/images/svg/up-down.svg is excluded by !**/*.svg
• public/logo192.png is excluded by !**/*.png
• public/markdown/images/install1.png is excluded by !**/*.png
• public/markdown/images/install2.png is excluded by !**/*.png
• src/assets/css/app.css.map is excluded by !**/*.map
• src/assets/images/blank.png is excluded by !**/*.png
• src/assets/images/bronze.png is excluded by !**/*.png
• src/assets/images/defaultImg.png is excluded by !**/*.png
• src/assets/images/gold.png is excluded by !**/*.png
• src/assets/images/palisadoes_logo.png is excluded by !**/*.png
• src/assets/images/silver.png is excluded by !**/*.png
• src/assets/images/talawa-logo-600x600.png is excluded by !**/*.png
• src/assets/images/talawa-logo-dark-200x200.png is excluded by !**/*.png
• src/assets/images/talawa-logo-lite-200x200.png is excluded by !**/*.png
• src/assets/svgs/Attendance.svg is excluded by !**/*.svg
• src/assets/svgs/actionItem.svg is excluded by !**/*.svg
• src/assets/svgs/admin.svg is excluded by !**/*.svg
• src/assets/svgs/agenda-category-icon.svg is excluded by !**/*.svg
• src/assets/svgs/agenda-items.svg is excluded by !**/*.svg
• src/assets/svgs/angleRight.svg is excluded by !**/*.svg
• src/assets/svgs/article.svg is excluded by !**/*.svg
• src/assets/svgs/blockUser.svg is excluded by !**/*.svg
• src/assets/svgs/blockedUser.svg is excluded by !**/*.svg
• src/assets/svgs/cardItemDate.svg is excluded by !**/*.svg
• src/assets/svgs/cardItemEvent.svg is excluded by !**/*.svg
• src/assets/svgs/cardItemLocation.svg is excluded by !**/*.svg
• src/assets/svgs/chat.svg is excluded by !**/*.svg
• src/assets/svgs/checkInRegistrants.svg is excluded by !**/*.svg
• src/assets/svgs/dashboard.svg is excluded by !**/*.svg
• src/assets/svgs/date.svg is excluded by !**/*.svg
• src/assets/svgs/event.svg is excluded by !**/*.svg
• src/assets/svgs/events.svg is excluded by !**/*.svg
• src/assets/svgs/flask.svg is excluded by !**/*.svg
• src/assets/svgs/funds.svg is excluded by !**/*.svg
• src/assets/svgs/key.svg is excluded by !**/*.svg
• src/assets/svgs/listEventRegistrants.svg is excluded by !**/*.svg
• src/assets/svgs/location.svg is excluded by !**/*.svg
• src/assets/svgs/logout.svg is excluded by !**/*.svg
• src/assets/svgs/media.svg is excluded by !**/*.svg
• src/assets/svgs/newChat.svg is excluded by !**/*.svg
• src/assets/svgs/organizations.svg is excluded by !**/*.svg
• src/assets/svgs/palisadoes.svg is excluded by !**/*.svg
• src/assets/svgs/people.svg is excluded by !**/*.svg
• src/assets/svgs/plugins.svg is excluded by !**/*.svg
• src/assets/svgs/post.svg is excluded by !**/*.svg
• src/assets/svgs/posts.svg is excluded by !**/*.svg
• src/assets/svgs/requests.svg is excluded by !**/*.svg
• src/assets/svgs/roles.svg is excluded by !**/*.svg
• src/assets/svgs/settings.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Facebook-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Github-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Instagram-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Linkedin-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Reddit-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Slack-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/X-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/social-icons/Youtube-Logo.svg is excluded by !**/*.svg
• src/assets/svgs/tag.svg is excluded by !**/*.svg
• src/assets/svgs/tags.svg is excluded by !**/*.svg
• src/assets/svgs/talawa.svg is excluded by !**/*.svg
• src/assets/svgs/user.svg is excluded by !**/*.svg
• src/assets/svgs/userEvent.svg is excluded by !**/*.svg
• src/assets/svgs/users.svg is excluded by !**/*.svg
• src/assets/svgs/venues.svg is excluded by !**/*.svg
• src/assets/talawa-logo-lite-200x200.png is excluded by !**/*.png

📒 Files selected for processing (82)

• .coderabbit.yaml (1 hunks)
• .env.example (1 hunks)
• .eslintignore (1 hunks)
• .eslintrc.json (4 hunks)
• .github/ISSUE_TEMPLATE/bug-report.md (2 hunks)
• .github/ISSUE_TEMPLATE/feature-request.md (2 hunks)
• .github/dependabot.yaml (1 hunks)
• .github/pull_request_template.md (2 hunks)
• .github/workflows/README.md (1 hunks)
• .github/workflows/auto-label.json5 (1 hunks)
• .github/workflows/check-tsdoc.js (1 hunks)
• .github/workflows/ci.yml (0 hunks)
• .github/workflows/codeql-analysis.yml (0 hunks)
• .github/workflows/codeql-codescan.yml (1 hunks)
• .github/workflows/compare_translations.py (1 hunks)
• .github/workflows/countline.py (1 hunks)
• .github/workflows/eslint_disable_check.py (1 hunks)
• .github/workflows/issue.yml (1 hunks)
• .github/workflows/linter.yml (0 hunks)
• .github/workflows/npm-publish.yml (0 hunks)
• .github/workflows/pull-request-target.yml (1 hunks)
• .github/workflows/pull-request.yml (1 hunks)
• .github/workflows/push.yml (1 hunks)
• .github/workflows/stale.yml (1 hunks)
• .github/workflows/talawa_admin_md_mdx_format_adjuster.py (1 hunks)
• .gitignore (2 hunks)
• .husky/post-merge (1 hunks)
• .husky/pre-commit (1 hunks)
• .lintstagedrc.json (1 hunks)
• .node-version (1 hunks)
• .prettierignore (1 hunks)
• .prettierrc (1 hunks)
• CODEOWNERS (1 hunks)
• CODE_OF_CONDUCT.md (1 hunks)
• CODE_STYLE.md (1 hunks)
• CONTRIBUTING.md (2 hunks)
• DOCUMENTATION.md (1 hunks)
• Docker_Container/.dockerignore (0 hunks)
• Docker_Container/README.md (0 hunks)
• Docker_Container/docker-compose.yml (0 hunks)
• Docker_Container/dockerfile (0 hunks)
• INSTALLATION.md (1 hunks)
• ISSUE_GUIDELINES.md (1 hunks)
• ISSUE_TEMPLATE.md (0 hunks)
• PR-guidelines.md (0 hunks)
• PR_GUIDELINES.md (1 hunks)
• PULL_REQUEST_TEMPLATE.md (0 hunks)
• README.md (3 hunks)
• config/babel.config.cjs (1 hunks)
• config/vite.config.ts (1 hunks)
• index.html (1 hunks)
• issue-guidelines.md (0 hunks)
• jest-preview.config.ts (1 hunks)
• jest.config.js (1 hunks)
• package.json (2 hunks)
• public/index.html (0 hunks)
• public/locales/en/common.json (1 hunks)
• public/locales/en/errors.json (1 hunks)
• public/locales/en/translation.json (1 hunks)
• public/locales/fr/common.json (1 hunks)
• public/locales/fr/errors.json (1 hunks)
• public/locales/fr/translation.json (1 hunks)
• public/locales/hi/common.json (1 hunks)
• public/locales/hi/errors.json (1 hunks)
• public/locales/hi/translation.json (1 hunks)
• public/locales/sp/common.json (1 hunks)
• public/locales/sp/errors.json (1 hunks)
• public/locales/sp/translation.json (1 hunks)
• public/locales/zh/common.json (1 hunks)
• public/locales/zh/errors.json (1 hunks)
• public/locales/zh/translation.json (1 hunks)
• public/manifest.json (1 hunks)
• schema.graphql (1 hunks)
• scripts/__mocks__/@dicebear/collection.ts (1 hunks)
• scripts/__mocks__/@dicebear/core.ts (1 hunks)
• scripts/__mocks__/@pdfme/generator.test.ts (1 hunks)
• scripts/__mocks__/@pdfme/generator.ts (1 hunks)
• scripts/__mocks__/fileMock.js (1 hunks)
• scripts/custom-test-env.js (1 hunks)
• scripts/githooks/check-localstorage-usage.js (1 hunks)
• scripts/githooks/update-toc.js (1 hunks)
• setup.ts (1 hunks)

⛔ Files not processed due to max files limit (28)

• src/App.test.tsx
• src/App.tsx
• src/Constant/constant.spec.ts
• src/Constant/constant.ts
• src/GraphQl/Mutations/ActionItemCategoryMutations.ts
• src/GraphQl/Mutations/ActionItemMutations.ts
• src/GraphQl/Mutations/AgendaCategoryMutations.ts
• src/GraphQl/Mutations/AgendaItemMutations.ts
• src/GraphQl/Mutations/CampaignMutation.ts
• src/GraphQl/Mutations/CommentMutations.ts
• src/GraphQl/Mutations/EventAttendeeMutations.ts
• src/GraphQl/Mutations/EventVolunteerMutation.ts
• src/GraphQl/Mutations/FundMutation.ts
• src/GraphQl/Mutations/OrganizationMutations.ts
• src/GraphQl/Mutations/PledgeMutation.ts
• src/GraphQl/Mutations/TagMutations.ts
• src/GraphQl/Mutations/VenueMutations.ts
• src/GraphQl/Mutations/mutations.ts
• src/GraphQl/Queries/ActionItemCategoryQueries.ts
• src/GraphQl/Queries/ActionItemQueries.ts
• src/GraphQl/Queries/AgendaCategoryQueries.ts
• src/GraphQl/Queries/AgendaItemQueries.ts
• src/GraphQl/Queries/EventVolunteerQueries.ts
• src/GraphQl/Queries/OrganizationQueries.ts
• src/GraphQl/Queries/PlugInQueries.ts
• src/GraphQl/Queries/Queries.ts
• src/GraphQl/Queries/fundQueries.ts
• src/GraphQl/Queries/userTagQueries.ts

💤 Files with no reviewable changes (13)

• .github/workflows/ci.yml
• .github/workflows/codeql-analysis.yml
• .github/workflows/linter.yml
• .github/workflows/npm-publish.yml
• Docker_Container/.dockerignore
• Docker_Container/README.md
• Docker_Container/docker-compose.yml
• Docker_Container/dockerfile
• ISSUE_TEMPLATE.md
• PR-guidelines.md
• PULL_REQUEST_TEMPLATE.md
• issue-guidelines.md
• public/index.html

✅ Files skipped from review due to trivial changes (33)

• .coderabbit.yaml
• .env.example
• .eslintignore
• .github/dependabot.yaml
• .github/workflows/auto-label.json5
• .gitignore
• .husky/pre-commit
• .lintstagedrc.json
• .node-version
• .prettierignore
• .prettierrc
• CODEOWNERS
• config/babel.config.cjs
• config/vite.config.ts
• index.html
• jest-preview.config.ts
• public/locales/en/common.json
• public/locales/en/errors.json
• public/locales/en/translation.json
• public/locales/fr/common.json
• public/locales/fr/errors.json
• public/locales/fr/translation.json
• public/locales/hi/common.json
• public/locales/hi/translation.json
• public/locales/sp/errors.json
• public/locales/sp/translation.json
• public/locales/zh/common.json
• public/locales/zh/errors.json
• public/locales/zh/translation.json
• scripts/mocks/@dicebear/collection.ts
• scripts/mocks/@dicebear/core.ts
• scripts/mocks/fileMock.js
• scripts/githooks/update-toc.js

🧰 Additional context used

🪛 Markdownlint (0.35.0)

.github/ISSUE_TEMPLATE/bug-report.md

36-36: null
Bare URL used

(MD034, no-bare-urls)

---

33-33: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

.github/ISSUE_TEMPLATE/feature-request.md

28-28: null
Bare URL used

(MD034, no-bare-urls)

---

25-25: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

CODE_STYLE.md

128-128: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

129-129: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

130-130: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

131-131: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

132-132: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

133-133: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

134-134: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

135-135: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

136-136: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

137-137: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

164-164: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

165-165: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

166-166: Expected: 0; Actual: 2
Unordered list indentation

(MD007, ul-indent)

---

57-57: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

73-73: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

75-75: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

92-92: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

190-190: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

230-230: null
Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

58-58: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

65-65: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

78-78: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

95-95: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

158-158: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

173-173: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

181-181: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

239-239: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

245-245: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

251-251: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

CONTRIBUTING.md

104-104: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

113-113: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

128-128: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

139-139: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

143-143: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

158-158: null
No empty links

(MD042, no-empty-links)

---

159-159: null
No empty links

(MD042, no-empty-links)

---

161-161: null
No empty links

(MD042, no-empty-links)

DOCUMENTATION.md

25-25: null
Bare URL used

(MD034, no-bare-urls)

INSTALLATION.md

321-321: Expected: h3; Actual: h4
Heading levels should only increment by one level at a time

(MD001, heading-increment)

---

33-33: Expected: 4; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

34-34: Expected: 4; Actual: 6
Unordered list indentation

(MD007, ul-indent)

---

95-95: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

105-105: null
Bare URL used

(MD034, no-bare-urls)

---

142-142: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

154-154: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

164-164: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

188-188: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

194-194: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

200-200: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

208-208: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

214-214: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

220-220: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

240-240: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

256-256: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

264-264: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

270-270: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

292-292: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

300-300: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

313-313: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

327-327: Expected: fenced; Actual: indented
Code block style

(MD046, code-block-style)

---

335-335: Expected: fenced; Actual: indented
Code block style

(MD046, code-block-style)

---

178-178: Expected: #setting-up-react_app_talawa_url-in-env-file; Actual: #setting-up-REACT_APP_TALAWA_URL-in-env-file
Link fragments should be valid

(MD051, link-fragments)

---

178-178: Expected: #setting-up-react_app_recaptcha_site_key-in-env-file; Actual: #setting-up-REACT_APP_RECAPTCHA_SITE_KEY-in-env-file
Link fragments should be valid

(MD051, link-fragments)

PR_GUIDELINES.md

31-31: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

39-39: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

README.md

53-53: null
Multiple spaces after hash on atx style heading

(MD019, no-multiple-space-atx)

🪛 LanguageTool

.github/workflows/README.md

[uncategorized] ~13-~13: Possible missing comma found.
Context: ...ding on the type of workflow. Whenever possible you must ensure that: 1. The file roles...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[duplication] ~24-~24: Possible typo: you repeated a word
Context: ...ors: 1. Place all actions related to to this in the pull-request-target.yml f...

(ENGLISH_WORD_REPEAT_RULE)

---

[uncategorized] ~35-~35: The abbreviation “e.g.” (= for example) requires two periods.
Context: ...orrectly if they have a dedicated file (eg. CodeQL) ## Scripts Follow these gui...

(E_G)

CODE_OF_CONDUCT.md

[duplication] ~11-~11: Possible typo: you repeated a word
Context: ...-responsibilities) - Scope - Enforcement - Enforcement Guidelines ...

(ENGLISH_WORD_REPEAT_RULE)

CODE_STYLE.md

[style] ~127-~127: Consider removing “of” to be more concise
Context: ...tories of src assets - This houses all of the static assets used in the project - `...

(ALL_OF_THE)

---

[style] ~128-~128: Consider removing “of” to be more concise
Context: ... in the project - css - This houses all of the css files used in the project - `imag...

(ALL_OF_THE)

---

[style] ~129-~129: Consider removing “of” to be more concise
Context: ... the project - images - This houses all of the images used in the project - scss -...

(ALL_OF_THE)

---

[style] ~130-~130: Consider removing “of” to be more concise
Context: ...in the project - scss - This houses all of the scss files used in the project - `c...

(ALL_OF_THE)

---

[grammar] ~134-~134: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ...rms - _talawa.scss - Partial Sass file for Talawa - _utilities.scss - Pa...

(HE_VERB_AGR)

---

[grammar] ~135-~135: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ... - _utilities.scss - Partial Sass file for utilities - _variables.scss -...

(HE_VERB_AGR)

---

[grammar] ~136-~136: The singular proper name ‘Sass’ must be used with a third-person or a past tense verb.
Context: ... - _variables.scss - Partial Sass file for variables - app.scss - Main S...

(HE_VERB_AGR)

---

[style] ~141-~141: Consider removing “of” to be more concise
Context: ...views/screens Constant - This houses all of the constants used in the project `GraphQl...

(ALL_OF_THE)

---

[style] ~143-~143: Consider removing “of” to be more concise
Context: ...in the project GraphQl - This houses all of the GraphQL queries and mutations used in t...

(ALL_OF_THE)

---

[style] ~145-~145: Consider removing “of” to be more concise
Context: ...in the project screens - This houses all of the views/screens to be navigated through i...

(ALL_OF_THE)

---

[style] ~147-~147: Consider removing “of” to be more concise
Context: ... in Talawa-Admin state - This houses all of the state management code for the project ...

(ALL_OF_THE)

---

[uncategorized] ~165-~165: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...following order: - React imports - Third party imports - Local imports If there is...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

CONTRIBUTING.md

[style] ~27-~27: This expression usually appears with a “please” in front of it.
Context: ...DUCT.md) to understand what this means. Let us know immediately if you have unacceptable ex...

(INSERT_PLEASE)

---

[uncategorized] ~34-~34: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...)" videos are extremely helpful for new open source contributors. ## Ways to Contribute I...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

[grammar] ~62-~62: A determiner may be missing.
Context: ...l Request guidelines](PR_GUIDELINES.md) is best resource to follow to start working on ...

(THE_SUPERLATIVE)

---

[uncategorized] ~68-~68: Loose punctuation mark.
Context: ...ushed to the main branch: - develop: For unstable code and bug fixing - `mai...

(UNLIKELY_OPENING_PUNCTUATION)

---

[uncategorized] ~69-~69: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...d bug fixing - main: Where the stable production ready code lies. This is our default branch. ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

[typographical] ~73-~73: Consider adding a comma.
Context: ...ultiple developers are working on issues there is bound to be a conflict of interest (...

(IF_THERE_COMMA)

---

[typographical] ~73-~73: Consider adding a comma after ‘Usually’ for more clarity.
Context: ...licts) among issues, PRs or even ideas. Usually these conflicts are resolved in a **Fir...

(RB_LY_COMMA)

---

[grammar] ~73-~73: Did you mean “served” (as in the idiom ‘first come, first served’)?
Context: ...ts are resolved in a First Come First Serve basis however there are certain excep...

(FIRST_SERVED)

---

[grammar] ~75-~75: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...tant to ask the author of the PR in the slack channel or in their PRs or issues thems...

(ON_SKYPE)

---

[style] ~77-~77: ‘Last but not the least’ might be wordy. Consider a shorter alternative.
Context: ...y and test that function when needed. - Last but not the least, communication is important make sure t...

(EN_WORDINESS_PREMIUM_LAST_BUT_NOT_THE_LEAST)

---

[grammar] ~77-~77: It seems that “to” is missing before the verb.
Context: ...t the least, communication is important make sure to talk to other contributors, in ...

(MISSING_TO_BETWEEN_BE_AND_VB)

---

[grammar] ~77-~77: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ... other contributors, in these cases, in slack channel or in a issue/PR thread. - As a...

(ON_SKYPE)

---

[misspelling] ~77-~77: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ... in these cases, in slack channel or in a issue/PR thread. - As a last resort the...

(EN_A_VS_AN)

---

[typographical] ~78-~78: It appears that a comma is missing.
Context: ...el or in a issue/PR thread. - As a last resort the Admins would be responsible for dec...

(DURING_THAT_TIME_COMMA)

---

[grammar] ~135-~135: The operating system from Apple is written “macOS”.
Context: ...r packages can be found for Windows and MacOS. 6. The currently acceptable c...

(MAC_OS)

---

[uncategorized] ~165-~165: Possible missing comma found.
Context: ...using: git push origin <branch_name>.(Here branch name must be name of the branch ...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[uncategorized] ~165-~165: Possible missing article found.
Context: ...: git push origin <branch_name>.(Here branch name must be name of the branch you wan...

(AI_HYDRA_LEO_MISSING_THE)

---

[uncategorized] ~165-~165: Possible missing article found.
Context: ...branch_name>`.(Here branch name must be name of the branch you want to push the chan...

(AI_HYDRA_LEO_MISSING_THE)

---

[grammar] ~178-~178: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...dation/talawa) for the link to join our slack channel. 1. We also have a technical em...

(ON_SKYPE)

DOCUMENTATION.md

[grammar] ~25-~25: The modal verb ‘should’ requires the verb’s base form.
Context: ...f docs.talawa.io should automatically launched in your browser at http://localhost:300...

(MD_BASEFORM)

---

[grammar] ~26-~26: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...ttp://localhost:3000/ 1. Add/modify the markdown documents to the docs/ directory of t...

(MARKDOWN_NNP)

---

[uncategorized] ~32-~32: The preposition “to” seems more likely in this position.
Context: ... PLEASE do not add markdown files in this repository. Add them to `talawa-do...

(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)

INSTALLATION.md

[duplication] ~25-~25: Possible typo: you repeated a word
Context: ...](#running-talawa-admin) - Accessing Talawa-Admin - [Talawa-Admin Registration](#talawa-admin-registratio...

(ENGLISH_WORD_REPEAT_RULE)

---

[typographical] ~55-~55: It appears that a comma is missing.
Context: ... that follow. # Prerequisites In this section we'll explain how to set up all the pre...

(DURING_THAT_TIME_COMMA)

---

[uncategorized] ~61-~61: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: .... Basic git knowledge is required for open source contribution so make sure you're comfor...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

[grammar] ~67-~67: The word “setup” is a noun. The verb is spelled with a space.
Context: ...avigate to the folder where you want to setup the repository. 2. Open a cmd (Window...

(NOUN_VERB_CONFUSION)

---

[grammar] ~68-~68: The operating system from Apple is written “macOS”.
Context: ...cmd (Windows) or terminal (Linux or MacOS) session in this folder. 1. An easy ...

(MAC_OS)

---

[uncategorized] ~70-~70: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...e option based on your OS. 3. For Our Open Source Contributor Software Developers: ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

[grammar] ~102-~102: The operating system from Apple is written “macOS”.
Context: ...node.jspackages in Windows, Linux and MacOS. 1. For Windows: 1. first install...

(MAC_OS)

---

[duplication] ~116-~116: Possible typo: you repeated a word
Context: ... 5. Save the document. 6. Exit notepad 7. Exit PowerShell 8. This will ensure...

(ENGLISH_WORD_REPEAT_RULE)

---

[grammar] ~119-~119: The operating system from Apple is written “macOS”.
Context: ...t version of node.js 2. For Linux and MacOS, use the terminal window. 1. install...

(MAC_OS)

---

[grammar] ~123-~123: The word “setup” is a noun. The verb is spelled with a white space.
Context: ... the respective recommended commands to setup your node environment 3. This wil...

(NOUN_VERB_CONFUSION)

---

[uncategorized] ~162-~162: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...at runtime. It is not a part of the repo and you will have to create it. For a sampl...

(COMMA_COMPOUND_SENTENCE)

---

[grammar] ~228-~228: The word “setup” is a noun. The verb is spelled with a space.
Context: ...E_KEY in .env file You may not want to setup reCAPTCHA since the project will still ...

(NOUN_VERB_CONFUSION)

---

[grammar] ~232-~232: The word “setup” is a noun. The verb is spelled with a space.
Context: ...ad the following steps. If you want to setup Google reCAPTCHA now, you may refer to ...

(NOUN_VERB_CONFUSION)

---

[typographical] ~246-~246: Except for inverted sentences, ‘need them’ requires a question mark at the end of the sentence.
Context: ...t need them or want to keep the console clean # Post Configuration Steps It's now t...

(MD_PRP_QUESTION_MARK)

---

[uncategorized] ~261-~261: Did you mean: “By default,”?
Context: ...n serve ``` ## Accessing Talawa-Admin By default talawa-admin runs on port `4321` on y...

(BY_DEFAULT_COMMA)

---

[grammar] ~311-~311: The word ‘lint’ is a noun or an adjective. A verb or adverb is missing or misspelled here, or maybe a comma is missing.
Context: ...w.webp) ## Linting code files You can lint your code files using this command: ``...

(PRP_MD_NN)

ISSUE_GUIDELINES.md

[uncategorized] ~2-~2: Loose punctuation mark.
Context: # Issue Report Guidelines 👍🎉 First off, thanks for taking t...

(UNLIKELY_OPENING_PUNCTUATION)

---

[style] ~4-~4: Consider a shorter alternative to avoid wordiness.
Context: ...ing the time to contribute! 🎉👍 In order to give everyone a chance to submit a issu...

(IN_ORDER_TO_PREMIUM)

---

[misspelling] ~5-~5: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ...der to give everyone a chance to submit a issues reports and contribute to the Ta...

(EN_A_VS_AN)

---

[typographical] ~24-~24: Consider adding a comma here.
Context: ...> ___ ## Issue Management In all cases please use the [GitHub open issue search](http...

(PLEASE_COMMA)

---

[uncategorized] ~27-~27: A comma might be missing here.
Context: ...reported. ### New Issues To create new issues follow these steps: 1. Your issue may ...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

---

[style] ~30-~30: Consider using a different verb for a more formal wording.
Context: .... 1. Verify whether the issue has been fixed by trying to reproduce it using the lat...

(FIX_RESOLVE)

---

[style] ~35-~35: The wording of this phrase can be improved.
Context: ...lcome contributors who find new ways to make the code better. ### Existing Issues You can also be ...

(MAKE_STYLE_BETTER)

---

[grammar] ~44-~44: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...butors to assign it to you in #talawa slack channel. Working on these types of exi...

(ON_SKYPE)

---

[grammar] ~53-~53: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...ew Issues 1. Join our #talawa-github slack channel for automatic issue and pull re...

(ON_SKYPE)

---

[grammar] ~57-~57: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...lines 1. Discuss issues in our various slack channels when necessary 2. Please do no...

(ON_SKYPE)

---

[typographical] ~57-~57: Consider adding a comma here.
Context: ...ur various slack channels when necessary 2. Please do not derail or troll issues. 3. Keep...

(PLEASE_COMMA)

PR_GUIDELINES.md

[uncategorized] ~2-~2: Loose punctuation mark.
Context: # Pull Request Guidelines 👍🎉 First off, thanks for taking t...

(UNLIKELY_OPENING_PUNCTUATION)

---

[style] ~4-~4: Consider a shorter alternative to avoid wordiness.
Context: ...ing the time to contribute! 🎉👍 In order to give everyone a chance to submit a pull...

(IN_ORDER_TO_PREMIUM)

---

[style] ~46-~46: Style-wise, it’s not ideal to insert an adverb (‘manually’) in the middle of an infinitive construction (‘to test’). Try moving the adverb to avoid split infinitives.
Context: ..., you'll need to tell us what steps you followed to manually test your changes. 1. Please read our [CONTRIBUTING.md](C...

(SPLIT_INFINITIVE)

---

[style] ~56-~56: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...o be closed. The quality of our code is very important to us. Therefore we make experienced ma...

(EN_WEAK_ADJECTIVE)

---

[uncategorized] ~56-~56: A comma may be missing after the conjunctive/linking adverb ‘Therefore’.
Context: ...ty of our code is very important to us. Therefore we make experienced maintainers of our ...

(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...check if all tests are passing; if not, fix the issues and then create a pull reque...

(FIX_RESOLVE)

---

[style] ~64-~64: This expression is wordy and overused. Consider replacing it with a more concise and formal alternative.
Context: ...wer your questions, but we'll get to it sooner or later. @mentioning someone just adds to the p...

(SOONER_OR_LATER)

---

[uncategorized] ~64-~64: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...adds to the pile of notifications we get and it won't make us look at your issue fas...

(COMMA_COMPOUND_SENTENCE)

---

[style] ~65-~65: Consider shortening or rephrasing this to strengthen your wording.
Context: ...ue faster. 1. Do not force push. If you make changes to your pull request, please simply add a ...

(MAKE_CHANGES)

README.md

[uncategorized] ~56-~56: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...)" videos are extremely helpful for new open source contributors.

(EN_COMPOUND_ADJECTIVE_INTERNAL)

🪛 yamllint (1.29.0-1)

.github/workflows/codeql-codescan.yml

[error] 6-6: trailing spaces

(trailing-spaces)

---

[error] 17-17: trailing spaces

(trailing-spaces)

---

[error] 20-20: trailing spaces

(trailing-spaces)

---

[warning] 31-31: wrong indentation: expected 6 but found 7

(indentation)

---

[warning] 37-37: wrong indentation: expected 11 but found 10

(indentation)

.github/workflows/issue.yml

[error] 6-6: trailing spaces

(trailing-spaces)

---

[warning] 15-15: wrong indentation: expected 4 but found 6

(indentation)

---

[warning] 66-66: too many blank lines

(1 > 0) (empty-lines)

.github/workflows/pull-request-target.yml

[error] 6-6: trailing spaces

(trailing-spaces)

---

[error] 13-13: trailing spaces

(trailing-spaces)

---

[error] 15-15: trailing spaces

(trailing-spaces)

---

[error] 36-36: trailing spaces

(trailing-spaces)

---

[error] 42-42: trailing spaces

(trailing-spaces)

---

[error] 67-67: trailing spaces

(trailing-spaces)

.github/workflows/pull-request.yml

[error] 49-49: trailing spaces

(trailing-spaces)

---

[error] 60-60: trailing spaces

(trailing-spaces)

---

[error] 63-63: trailing spaces

(trailing-spaces)

---

[error] 92-92: trailing spaces

(trailing-spaces)

---

[error] 126-126: trailing spaces

(trailing-spaces)

---

[error] 129-129: trailing spaces

(trailing-spaces)

---

[error] 150-150: trailing spaces

(trailing-spaces)

---

[error] 157-157: trailing spaces

(trailing-spaces)

---

[error] 197-197: trailing spaces

(trailing-spaces)

---

[error] 201-201: trailing spaces

(trailing-spaces)

---

[error] 204-204: trailing spaces

(trailing-spaces)

---

[error] 205-205: trailing spaces

(trailing-spaces)

---

[error] 213-213: trailing spaces

(trailing-spaces)

---

[error] 243-243: trailing spaces

(trailing-spaces)

---

[error] 249-249: trailing spaces

(trailing-spaces)

---

[error] 251-251: trailing spaces

(trailing-spaces)

.github/workflows/push.yml

[error] 6-6: trailing spaces

(trailing-spaces)

---

[error] 17-17: trailing spaces

(trailing-spaces)

---

[error] 18-18: trailing spaces

(trailing-spaces)

---

[warning] 20-20: wrong indentation: expected 2 but found 4

(indentation)

---

[error] 21-21: trailing spaces

(trailing-spaces)

---

[error] 50-50: trailing spaces

(trailing-spaces)

---

[warning] 62-62: too many blank lines

(1 > 0) (empty-lines)

.github/workflows/stale.yml

[error] 6-6: trailing spaces

(trailing-spaces)

---

[error] 20-20: trailing spaces

(trailing-spaces)

---

[error] 21-21: trailing spaces

(trailing-spaces)

🪛 Ruff (0.7.0)

.github/workflows/compare_translations.py

135-135: Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling

(B904)

.github/workflows/eslint_disable_check.py

61-61: Loop control variable dirs not used within loop body

Rename unused dirs to _dirs

(B007)

🪛 actionlint (1.7.3)

.github/workflows/pull-request.yml

61-61: property "changed_files" is not defined in object type {changed-files: {conclusion: string; outcome: string; outputs: {string => string}}}

(expression)

---

62-62: shellcheck reported issue in this script: SC2086:info:1:12: Double quote to prevent globbing and word splitting

(shellcheck)

---

79-79: "github.event.pull_request.head.ref" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions for more details

(expression)

---

207-207: shellcheck reported issue in this script: SC2043:warning:1:13: This loop will only ever run once. Bad quoting or missing glob/expansion?

(shellcheck)

🔇 Additional comments (36)

public/locales/hi/errors.json (1)

4-4: Verify placeholder usage consistency across languages

The messages use placeholders like {{msg}} and {{entity}}. Let's verify that these are used consistently across other language files.

Also applies to: 9-9, 10-10

✅ Verification successful

Placeholder usage is consistent across all language files

The verification shows that all language files (en, fr, zh, sp, hi) consistently use:

• {{msg}} in the "unknownError" message
• {{entity}} in both "errorOccurredCouldntCreate" and "errorLoading" messages

Each language file contains exactly 3 placeholders, maintaining perfect consistency across translations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check placeholder consistency across language files

# Find all error.json files and check for placeholder patterns
echo "Checking placeholder consistency across language files:"
fd "errors.json" public/locales -x grep -H "{{[^}]*}}"

# Compare placeholder counts across files
echo -e "\nComparing placeholder counts:"
for lang_dir in public/locales/*; do
  if [ -f "$lang_dir/errors.json" ]; then
    lang=$(basename "$lang_dir")
    count=$(grep -o "{{[^}]*}}" "$lang_dir/errors.json" | wc -l)
    echo "$lang: $count placeholders"
  fi
done

Length of output: 2904

public/manifest.json (1)

16-16: Verify logo512.png location

The icon path has been updated to "images/logo512.png". Let's verify that the file exists at this new location to prevent 404 errors.

✅ Verification successful

Path to logo512.png is valid and properly referenced

The verification confirms that:

• The file exists at the new location: public/images/logo512.png
• The only reference to logo512.png is in manifest.json, indicating no other files need updating

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the logo512.png exists in the new location
# and if there are any other references to the old path that need updating

# Check if file exists in new location
if [ -f "public/images/logo512.png" ]; then
    echo "✓ File exists at new location: public/images/logo512.png"
else
    echo "✗ File not found at: public/images/logo512.png"
fi

# Check for any references to the old path
rg -l "logo512.png" --type html --type js --type json --type ts

Length of output: 246

scripts/custom-test-env.js (2)

1-2: LGTM! Imports are correctly structured.

The imports are properly organized, importing the necessary components for the custom test environment.

---

1-16: Verify relationship with @testing-library/user-event upgrade.

This custom test environment seems focused on supporting @pdfme library, but the PR description mentions upgrading @testing-library/user-event. Please clarify if this environment setup is related to the package upgrade or if it should be in a separate PR.

.github/ISSUE_TEMPLATE/bug-report.md (1)

2-6: LGTM! Metadata changes improve consistency.

The changes to the metadata fields follow GitHub's conventions with consistent capitalization and lowercase label.

scripts/__mocks__/@pdfme/generator.ts (2)

1-9: LGTM! Well-structured type definitions

The type definitions are clear and maintain compatibility with the actual package types.

---

14-22: Consider enhancing mock fidelity for complex test scenarios

The current implementation provides a basic mock that returns valid Uint8Array data. While this is sufficient for basic testing, consider these potential enhancements:

1. Add validation for template structure beyond just length
2. Include PDF-specific markers (like EOF) for more realistic mocking
3. Consider reflecting input data in the output for more meaningful tests

However, the current implementation is acceptable if the tests only need to verify the function contract.

scripts/__mocks__/@pdfme/generator.test.ts (2)

1-2: LGTM! Clean and well-organized imports.

The imports are properly separated between values and types, following TypeScript best practices.

---

4-4: LGTM! Clear test suite organization.

The describe block clearly indicates the purpose of testing the mock implementation.

.github/pull_request_template.md (1)

51-51: Verify the contributing guide path

Let's ensure the contributing guide exists at the specified path.

✅ Verification successful

Contributing guide link is valid ✓

The contributing guide exists at the specified path CONTRIBUTING.md in the repository root, confirming that the link in the PR template is correct.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of CONTRIBUTING.md file
# Expected: File should exist in the repository root

if [ -f "CONTRIBUTING.md" ]; then
    echo "✓ CONTRIBUTING.md exists"
else
    echo "✗ CONTRIBUTING.md not found"
fi

Length of output: 87

.github/workflows/stale.yml (2)

14-16: Verify workflow scheduling coordination

The daily midnight schedule is reasonable, but let's verify it doesn't conflict with other scheduled workflows.

✅ Verification successful

No scheduling conflicts detected in GitHub workflows

The stale workflow's daily midnight schedule (0 0 * * *) is the only scheduled workflow in the repository, so there are no timing conflicts to be concerned about.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check scheduling of other workflow files
rg -l 'schedule:' .github/workflows/ | xargs rg 'cron:'

Length of output: 75

---

1-11: Verify the existence of the referenced README.md file

The header references a README.md file that should define what belongs in this workflow file. Let's verify its existence and content.

✅ Verification successful

The stale.yml workflow file should be renamed to follow the documented naming convention

Based on the README.md content, workflow files should be organized according to specific roles:

• issues.yml for issue-related actions
• pull-request-target.yml for first-time contributor PR actions
• pull-request.yml for all contributor PR actions
• push.yml for push-related actions

Exceptions are allowed only for:

1. Jobs with unique cron schedules
2. Jobs with unique path-specific triggers
3. Jobs that require dedicated files for functionality

Let's verify if this stale workflow falls under any exceptions:

---

The stale.yml workflow file is correctly placed as a separate file

The workflow file is properly configured as a standalone file because it falls under the documented exceptions in the README.md. Specifically:

1. It uses a unique cron schedule ("0 0 * * *") to run daily at midnight
2. It performs a specialized task (managing stale issues and PRs) that runs on a schedule

Therefore, it doesn't need to be consolidated into one of the main role-based files (issues.yml, pull-request.yml, etc.).

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if README.md exists in the workflows directory and contains relevant content
fd -t f "README.md" .github/workflows -x cat {}

Length of output: 2121

---

Script:

#!/bin/bash
# Check the stale.yml content for cron schedules or path triggers
cat .github/workflows/stale.yml

Length of output: 1960

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 6-6: trailing spaces

(trailing-spaces)

.github/workflows/check-tsdoc.js (1)

1-68: Verify the scope of changes

This new TSDoc validation script appears unrelated to the PR's primary objective of upgrading @testing-library/user-event. Please clarify why this file is included in this PR or consider moving it to a separate PR to maintain a focused scope of changes.

.github/workflows/push.yml (1)

12-17: Consider limiting branch triggers for resource optimization

The workflow currently runs on all branches ('**'). Consider limiting it to specific branches (e.g., main/develop) to optimize CI resources, unless coverage tracking is required for all feature branches.

🧰 Tools

🪛 yamllint (1.29.0-1)

[error] 17-17: trailing spaces

(trailing-spaces)

jest.config.js (3)

2-6: Remove commented code and verify fetch polyfill configuration.

The configuration switches from react-app-polyfill to whatwg-fetch. While this change might be intentional, it's important to verify that all fetch-related tests work correctly with this setup, especially considering the upgrade of @testing-library/user-event.

Also, please remove the commented-out code if it's no longer needed.

✅ Verification successful

The fetch polyfill configuration is appropriate for the codebase

The switch from react-app-polyfill to whatwg-fetch is valid as:

1. The codebase extensively uses fetch in tests (45+ test files)
2. setupTests.ts properly mocks the global fetch API (global.fetch = jest.fn())
3. The test setup includes all necessary configurations for the testing environment

Please remove the commented-out react-app-polyfill line as it's no longer needed.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for fetch usage in test files
rg -t js -t ts -t jsx -t tsx 'fetch\(' src/ --glob '**/*.{test,spec}.*'

Length of output: 101

---

Script:

#!/bin/bash
# Search for fetch usage in test files with correct file extensions
rg 'fetch\(' src/ -g '*.test.*' -g '*.spec.*'

# Also check for any test files that might use the fetch API
rg -l 'fetch' src/ -g '*.test.*' -g '*.spec.*'

# Look for setupTests.ts content to understand the test setup
fd setupTests.ts -x cat {}

Length of output: 3715

---

12-19: Verify babel configuration and transformer compatibility.

Please ensure that:

1. The referenced babel config file exists at './config/babel.config.cjs'
2. The transformers are compatible with the upgraded version of @testing-library/user-event

✅ Verification successful

Babel configuration and transformers are properly set up

The verification shows:

• Babel config exists with appropriate presets for React, TypeScript, and modern JavaScript
• All required transformers are installed:
  • [email protected]
  • [email protected]
  • @testing-library/[email protected]

The configuration is compatible with the testing setup and no issues were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if babel config exists
if [ ! -f "./config/babel.config.cjs" ]; then
    echo "Error: babel.config.cjs not found"
    exit 1
fi

# Check package.json for transformer dependencies
rg -l "jest-preview" package.json

Length of output: 89

---

Script:

#!/bin/bash
# Check the content of babel.config.cjs
cat ./config/babel.config.cjs

# Check package.json for relevant dependencies and their versions
rg "jest-preview|babel-jest|@testing-library/user-event" package.json -A 1 -B 1

Length of output: 812

---

27-35: Verify mock files existence and necessity.

Please ensure that all referenced mock files exist in the scripts/mocks directory and are necessary for the testing setup.

✅ Verification successful

All mock files are present and justified by actual usage

The verification confirms:

• All mock files exist in their respective directories:
  • scripts/__mocks__/fileMock.js
  • scripts/__mocks__/@dicebear/{core.ts,collection.ts}
  • scripts/__mocks__/@pdfme/generator.ts
• The mocked modules are actively used in the codebase:
  • @dicebear modules are used in Avatar component
  • @pdfme modules are used in CheckIn components
  • SVG mocking is necessary for handling SVG imports

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if all mock files exist
for mock in "@dicebear/core.ts" "@dicebear/collection.ts" "fileMock.js" "@pdfme/generator.ts"; do
    if [ ! -f "./scripts/__mocks__/$mock" ]; then
        echo "Missing mock file: $mock"
    fi
done

# Check if these modules are actually used in tests
rg -t js -t ts -t jsx -t tsx '@dicebear|@pdfme' src/ --glob '**/*.{test,spec}.*'

Length of output: 716

---

Script:

#!/bin/bash
# Check if mock directories and files exist
ls -la scripts/__mocks__/ 2>/dev/null || echo "Main mocks directory not found"
ls -la scripts/__mocks__/@dicebear/ 2>/dev/null || echo "@dicebear mocks directory not found"
ls -la scripts/__mocks__/@pdfme/ 2>/dev/null || echo "@pdfme mocks directory not found"

# Search for test files using these modules (fixing the file type flags)
rg -t ts -t js '@dicebear|@pdfme' --glob '**/*.{test,spec}.{ts,js}'

# Search for actual usage of these modules in source files
rg -t ts -t js '@dicebear|@pdfme' --glob '!**/*.{test,spec}.{ts,js}'

# Check for SVG imports in test files
rg -t ts -t js '\.svg' --glob '**/*.{test,spec}.{ts,js}'

Length of output: 1991

scripts/githooks/check-localstorage-usage.js (1)

1-9: LGTM! Clean and effective script setup.

The script setup is well-structured with appropriate imports and clean command-line argument handling.

.github/workflows/talawa_admin_md_mdx_format_adjuster.py (2)

15-17: LGTM!

The imports are appropriate, minimal, and well-organized.

---

1-96: Verify the relationship with package upgrade

This new script appears to be unrelated to the main PR objective of upgrading @testing-library/user-event. Please clarify why this MDX formatting script is included in this PR.

public/locales/sp/common.json (1)

79-79: Verify interpolation strings are properly translated

The interpolation variables ({{item}}, {{text}}) are correctly formatted, but ensure the surrounding text is properly translated and maintains proper Spanish grammar:

Also applies to: 83-85

✅ Verification successful

Interpolation strings are properly translated and grammatically correct

After comparing both English and Spanish translations, all interpolation variables are consistently used and the surrounding text maintains proper Spanish grammar and structure. For example:

• "Search results for {{text}}" → "Resultados de búsqueda para {{text}}"
• "{{item}} added Successfully" → "{{item}} agregado con éxito"
• "Remove User from {{org}}" → "Eliminar Usuario de {{org}}"

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other interpolation usage in Spanish translations
rg -g '*.json' -A 1 '{{.*}}' public/locales/sp/

Length of output: 131

---

Script:

#!/bin/bash
# Search for interpolation usage in Spanish translations with proper regex escaping
rg -g '*.json' '\{\{[^}]+\}\}' public/locales/sp/

Length of output: 1219

---

Script:

#!/bin/bash
# Let's also check the English translations to compare
rg -g '*.json' '\{\{[^}]+\}\}' public/locales/en/

Length of output: 1184

ISSUE_GUIDELINES.md (2)

7-20: LGTM! Well-structured table of contents

The table of contents is properly formatted with clear hierarchy and correct markdown link syntax.

---

48-51: LGTM! Clear feature request guidelines

The section provides clear guidance on submitting feature requests with appropriate emphasis on project scope and context requirements.

README.md (2)

24-32: LGTM! Well-structured table of contents

The table of contents is properly implemented using HTML comments for markers, making it maintainable and compatible with automatic TOC generators.

---

45-51: Verify the existence of all referenced documentation files

The documentation structure looks good, but let's verify that all referenced files exist in the repository.

✅ Verification successful

All referenced documentation files are present and correctly linked

The verification confirms that all documentation files mentioned in the README.md exist in the repository:

• INSTALLATION.md
• CONTRIBUTING.md
• CODE_OF_CONDUCT.md
• ISSUE_GUIDELINES.md
• PR_GUIDELINES.md

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if all referenced documentation files exist
files=(
  "INSTALLATION.md"
  "CONTRIBUTING.md"
  "CODE_OF_CONDUCT.md"
  "ISSUE_GUIDELINES.md"
  "PR_GUIDELINES.md"
)

for file in "${files[@]}"; do
  if [ ! -f "$file" ]; then
    echo "Missing file: $file"
  fi
done

Length of output: 420

---

Script:

#!/bin/bash
# Let's use fd to find these files as they might be in subdirectories
echo "Searching for documentation files:"
fd -t f -i "installation.md|contributing.md|code_of_conduct.md|issue_guidelines.md|pr_guidelines.md"

echo -e "\nChecking README.md content for any alternative paths:"
rg -i "installation\.md|contributing\.md|code_of_conduct\.md|issue_guidelines\.md|pr_guidelines\.md" README.md

Length of output: 1093

.eslintrc.json (3)

4-4: LGTM: Environment and extends configuration is well structured

The environment configuration properly includes Node.js support, and the extends section correctly layers TypeScript and Prettier configurations.

Also applies to: 14-16

---

42-42: Consider gradual adoption of strict TypeScript rules

Several TypeScript rules are set to "error" which might be too strict for an initial migration:

• explicit-module-boundary-types
• ban-ts-comment
• no-explicit-any
• Multiple strict type assertion rules

Consider a phased approach by temporarily setting some of these rules to "warn" to ease the transition.

Let's check the current TypeScript usage in the codebase:

Also applies to: 57-64

---

Line range hint 1-142: Verify the scope of ESLint changes

These extensive ESLint changes seem to go beyond the stated PR objective of upgrading @testing-library/user-event. Please clarify if these changes are necessary for the package upgrade or if they should be in a separate PR.

Let's check if these changes are related to the package upgrade:

CODE_OF_CONDUCT.md (1)

3-20: LGTM! Well-structured table of contents.

The addition of a table of contents with proper markdown anchors improves document navigation. The implementation follows markdown best practices using HTML comments for TOC markers.

🧰 Tools

🪛 LanguageTool

[duplication] ~11-~11: Possible typo: you repeated a word
Context: ...-responsibilities) - Scope - Enforcement - Enforcement Guidelines ...

(ENGLISH_WORD_REPEAT_RULE)

package.json (3)

117-130: Verify TypeScript types compatibility

The addition of multiple @types packages requires verification of TypeScript configuration and type compatibility.

✅ Verification successful

TypeScript configuration and types are compatible

The TypeScript configuration is properly set up with TypeScript v5.6.3 and the added type definitions are compatible with the project's configuration. The tsconfig.json has appropriate compiler options including strict type checking and React JSX support. The added @types packages in package.json are all from DefinitelyTyped and follow semantic versioning, ensuring compatibility.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check TypeScript config
test -f "tsconfig.json" && echo "TypeScript config exists" || echo "Missing TypeScript config"

# Look for any type errors in the codebase
fd -e ts -e tsx | xargs -I {} sh -c 'echo "Checking {}..." && tsc {} --noEmit --jsx react'

Length of output: 44413

---

Script:

#!/bin/bash
# Check TypeScript config content
test -f tsconfig.json && cat tsconfig.json

# Check package.json for TypeScript version and related configs
test -f package.json && cat package.json | grep -A 2 -B 2 '"typescript":'

Length of output: 895

---

5-6: Verify ESM compatibility across the codebase

The addition of "type": "module" indicates a migration to ES modules. This change requires verification of import statements across the codebase.

✅ Verification successful

Based on the results, I can now provide a final response:

ESM migration appears to be properly implemented across the codebase

The codebase shows consistent usage of ESM-style imports throughout:

• All imports use the import/export syntax rather than require()
• Only two instances of require() found, both in test files for mocking purposes
• Relative imports follow ESM conventions
• TypeScript/React files are using proper module syntax

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential CommonJS require statements that need to be converted to ESM imports
rg "require\(" --type ts --type tsx

# Check for .js extensions in import statements (needed for ESM)
rg "from ['\"](\.\/|\.\.\/)[^'\"]+['\"]\s*;" --type ts --type tsx

Length of output: 254

---

Script:

#!/bin/bash
# Check for potential CommonJS require statements
rg "require\("

# Check for relative imports without .js extension
rg "from ['\"](\./|\.\./)[^'\"]+['\"]"

# Check current JavaScript/TypeScript files
fd "\.(js|jsx|ts|tsx)$"

Length of output: 89621

---

46-51: ⚠️ Potential issue

Verify React 18 compatibility with testing libraries

The upgrade of React to v18.3.1 alongside @testing-library/user-event v13.5.0 requires careful verification:

1. @testing-library/react v16.0.1 seems outdated for React 18
2. @testing-library/user-event v13.5.0 might need newer @testing-library/react

Consider upgrading @testing-library/react to a version compatible with React 18, such as v13 or newer. The current version (v16.0.1) might cause compatibility issues.

Also applies to: 114-116

✅ Verification successful

Based on the analysis of the codebase through the executed scripts, I can now provide a final response:

React 18 upgrade appears compatible with testing setup

The codebase shows extensive use of @testing-library/react without any React 18-specific features (createRoot, useId, etc.) in the tests. The current testing setup using render method from @testing-library/react v16.0.1 remains compatible with React 18 as:

1. The tests are using standard render patterns that work across React versions
2. No React 18 concurrent features are being used that would require special test setup
3. @testing-library/user-event v13.5.0 is compatible with both React 17 and 18

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential React 18 features in tests that might be incompatible
rg "createRoot|useId|useDeferredValue|useTransition" --type test

# Look for existing test files that might need updates
fd -e test.tsx -e test.ts

Length of output: 11050

---

Script:

#!/bin/bash
# Check package.json for testing library versions
cat package.json | jq -r '.dependencies["@testing-library/react"], .dependencies["@testing-library/user-event"]'

# Search for React testing library usage patterns in test files
rg "@testing-library/react" -A 2

# Look for render method usage in tests which might need updates for React 18
ast-grep --pattern 'render($$$)'

Length of output: 132682

---

Script:

#!/bin/bash
# Check for React 18 specific imports and usage in test files
rg "createRoot|useId|useDeferredValue|useTransition" --type tsx --type ts --type jsx --type js

# Check for React testing library setup files
fd -e setup.ts -e setup.js -e setupTests.ts -e setupTests.js

# Look for test utilities or test setup files
rg "test-utils|testUtils" --type tsx --type ts --type jsx --type js

Length of output: 285

.github/workflows/pull-request.yml (1)

47-48: Verify the condition logic

The condition steps.changed-files.outputs.only_changed != 'true' seems counterintuitive. Should this check be inverted? Please verify the intended behavior.

✅ Verification successful

Let me check the context of these conditions by looking at the changed-files step setup.

---

Let me check the complete workflow file to understand how the only_changed output is being set and used.

---

The condition logic is correct and working as intended

The condition steps.changed-files.outputs.only_changed != 'true' is used consistently throughout the workflow to skip certain checks when only specific files have changed. This is a common pattern when using tj-actions/changed-files@v40 action to optimize CI by running checks only when necessary. The condition is used for:

• Format checking
• Type checking
• Linting
• Tests

The logic is correct because:

1. When only_changed is 'true', it means only specific files (configured in the action) have changed, so we skip the checks
2. When only_changed is not 'true', it means other files have changed too, so we run the checks

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check how the only_changed output is being used in other workflows
rg -A 2 "only_changed.*true" .github/workflows/

Length of output: 968

---

Script:

#!/bin/bash
# Check the changed-files step configuration
rg -B 5 -A 2 "id: changed-files" .github/workflows/pull-request.yml

Length of output: 1022

---

Script:

#!/bin/bash
# Get the complete workflow file
cat .github/workflows/pull-request.yml

Length of output: 9264

CONTRIBUTING.md (2)

7-23: LGTM! Well-structured table of contents

The addition of a clear table of contents improves document navigation.

---

Line range hint 1-179: Overall document structure and content improvements are excellent

The restructured document provides clearer guidance for contributors with comprehensive sections covering all aspects of contribution. The addition of detailed testing instructions and codecov setup is particularly valuable.

🧰 Tools

🪛 Markdownlint (0.35.0)

104-104: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

113-113: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

128-128: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

139-139: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

143-143: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

158-158: null
No empty links

(MD042, no-empty-links)

---

159-159: null
No empty links

(MD042, no-empty-links)

---

161-161: null
No empty links

(MD042, no-empty-links)

🪛 LanguageTool

[grammar] ~135-~135: The operating system from Apple is written “macOS”.
Context: ...r packages can be found for Windows and MacOS. 6. The currently acceptable c...

(MAC_OS)

---

[uncategorized] ~165-~165: Possible missing comma found.
Context: ...using: git push origin <branch_name>.(Here branch name must be name of the branch ...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[uncategorized] ~165-~165: Possible missing article found.
Context: ...: git push origin <branch_name>.(Here branch name must be name of the branch you wan...

(AI_HYDRA_LEO_MISSING_THE)

---

[uncategorized] ~165-~165: Possible missing article found.
Context: ...branch_name>`.(Here branch name must be name of the branch you want to push the chan...

(AI_HYDRA_LEO_MISSING_THE)

---

[grammar] ~178-~178: Did you mean the communication tool “Slack” (= proper noun, capitalized)?
Context: ...dation/talawa) for the link to join our slack channel. 1. We also have a technical em...

(ON_SKYPE)

.github/workflows/countline.py (1)

296-297: Ensure the main() function is called in the standard way

Check that the script uses the standard idiom for script execution.

[coderabbitai]

💡 Codebase verification

Consider using git diff @{1} HEAD instead of HEAD^ for post-merge hook

The verification confirms that the repository is using shallow clones, where HEAD^ might not be available. For post-merge hooks specifically, using @{1} (previous HEAD state) is more reliable than HEAD^ as it:

• Works with shallow clones
• Correctly references the pre-merge state
• Is specifically designed for merge scenarios

Suggested change:

git diff @{1} HEAD --exit-code -- ./package.json || npm install

🔗 Analysis chain

Verify the git diff command behavior across different Git clients.

The current command assumes HEAD^ is always available. However, this might fail in shallow clones or after the first commit.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the git diff command works in various scenarios

# Test 1: Check if we're in a shallow clone
if git rev-parse --is-shallow-repository; then
  echo "Warning: Repository is shallow cloned, HEAD^ might not be available"
fi

# Test 2: Check commit count to verify if HEAD^ would be available
COMMIT_COUNT=$(git rev-list --count HEAD)
if [ "$COMMIT_COUNT" -le 1 ]; then
  echo "Warning: Repository has 1 or fewer commits, HEAD^ won't be available"
fi

Length of output: 253

---

Script:

#!/bin/bash
# Let's check if there's any existing error handling or alternative approaches in the husky hooks
fd -t f -H . .husky/ -x cat {}

# Also check if there are any similar git diff patterns in the codebase that might have better handling
rg "git diff.*HEAD\^" -A 2 -B 2

Length of output: 280

[coderabbitai]

🛠️ Refactor suggestion

Fix inconsistent spacing and incomplete messages

There are several formatting issues in the error messages:

1. Remove trailing spaces after exclamation marks in "है! " and "मांगना! "
2. The message "उफ़! " appears incomplete and should include more context about what wasn't found

Apply these changes:

-  "talawaApiUnavailable": "तलवा-एपीआई सेवा उपलब्ध नहीं है! ",
+  "talawaApiUnavailable": "तलवा-एपीआई सेवा उपलब्ध नहीं है!",
-  "notAuthorised": "क्षमा मांगना! ",
+  "notAuthorised": "क्षमा मांगना!",
-  "notFoundMsg": "उफ़! ",
+  "notFoundMsg": "उफ़! आपके द्वारा खोजा गया पृष्ठ नहीं मिला।",

Also applies to: 5-5, 8-8

[coderabbitai]

⚠️ Potential issue

Critical: Icon size mismatch with filename

The size "16x16" is inconsistent with the filename "logo192.png" which suggests a 192x192 image. This mismatch could cause display issues or failed image loading.

-      "sizes": "16x16"
+      "sizes": "192x192"

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"sizes": "16x16"
	"sizes": "192x192"

[coderabbitai]

⚠️ Potential issue

Fix incorrect template text.

The "Additional details" section incorrectly references a "feature request" instead of a "bug report".

-Add any other context or screenshots about the feature request here.
+Add any other context or screenshots about the bug report here.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	Add any other context or screenshots about the feature request here.
	Add any other context or screenshots about the bug report here.

[coderabbitai]

🛠️ Refactor suggestion

Enhance language matrix for TypeScript support

Since this is a React project using TypeScript (as evidenced by the upgrade of @testing-library/user-event), the CodeQL analysis should include TypeScript scanning.

Update the language matrix:

matrix:
-  language: [ 'javascript' ]
+  language: [ 'javascript-typescript' ]

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	fail-fast: false
	matrix:
	language: [ 'javascript' ]
	fail-fast: false
	matrix:
	language: [ 'javascript-typescript' ]

[coderabbitai]

⚠️ Potential issue

Duplicate type UserPhone definitions

The type UserPhone is defined twice at lines 1348-1352 and 1407-1411. This redundancy can cause issues in schema compilation. Please retain only one definition to avoid conflicts.

-type UserPhone {
-  home: PhoneNumber
-  mobile: PhoneNumber
-  work: PhoneNumber
-}

Also applies to: 1407-1411

[coderabbitai]

⚠️ Potential issue

Duplicate enum EducationGrade definitions

The enum EducationGrade is defined twice at lines 244-261 and 1223-1240. Duplicate definitions can cause schema errors. Please remove one of the enum definitions.

-enum EducationGrade {
-  GRADE_1
-  GRADE_2
-  GRADE_3
-  GRADE_4
-  GRADE_5
-  GRADE_6
-  GRADE_7
-  GRADE_8
-  GRADE_9
-  GRADE_10
-  GRADE_11
-  GRADE_12
-  GRADUATE
-  KG
-  NO_GRADE
-  PRE_KG
-}

Also applies to: 1223-1240

[coderabbitai]

⚠️ Potential issue

Duplicate enum EmploymentStatus definitions

The enum EmploymentStatus is defined twice at lines 265-269 and 1242-1246. This duplication can lead to conflicts in the schema. Please remove one of the definitions.

-enum EmploymentStatus {
-  FULL_TIME
-  PART_TIME
-  UNEMPLOYED
-}

Also applies to: 1242-1246

[coderabbitai]

⚠️ Potential issue

Duplicate enum MaritalStatus definitions and typo correction

The enum MaritalStatus is defined twice at lines 491-498 and 1254-1261. Additionally, there is a misspelling of SEPARATED as SEPERATED at line 1258. Duplicate enums and typos can cause schema validation errors.

Please remove the duplicate enum definition and correct the spelling mistake.

-enum MaritalStatus {
-  DIVORCED
-  ENGAGED
-  MARRIED
-  SEPERATED
+  SEPARATED
-  SINGLE
-  WIDOWED
-}

Also applies to: 1254-1261

[coderabbitai]

🛠️ Refactor suggestion

Inconsistent parameter type in addOrganizationImage mutation

In the addOrganizationImage mutation at line 591, the parameter organizationId is of type String!. For consistency with other mutations and to utilize the GraphQL ID type, it should be of type ID!.

Please update the parameter type to ID!.

-  addOrganizationImage(file: String!, organizationId: String!): Organization!
+  addOrganizationImage(file: String!, organizationId: ID!): Organization!

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	addOrganizationImage(file: String!, organizationId: String!): Organization!
	addOrganizationImage(file: String!, organizationId: ID!): Organization!

[palisadoes]

This PR has too many submitted files.

Please ensure the following:

1. Fetch the latest upstream/develop files
2. Make your PR modifications based on the local copy of this develop-postgres branch
3. Submit your PRs against our develop-postgres branch.
4. Your source branch in your local repository must not be the same as the target branch

Closing