Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test PR to check if workflows break. #3159

Open
wants to merge 42 commits into
base: develop-postgres
Choose a base branch
from

Conversation

Suyash878
Copy link
Contributor

@Suyash878 Suyash878 commented Jan 5, 2025

What kind of change does this PR introduce?

Issue Number:

Fixes #

Did you add tests for your changes?

Snapshots/Videos:

If relevant, did you update the documentation?

Summary

Does this PR introduce a breaking change?

Other information

Have you read the contributing guide?

Summary by CodeRabbit

Release Notes

  • Linting Configuration

    • Introduced a new ESLint configuration file for enhanced linting setup.
    • Removed legacy ESLint configuration files.
    • Updated ESLint and related dependencies.
  • GraphQL

    • Added new user fund campaigns query.
  • Testing

    • Updated test configurations to support additional file types.
    • Minor improvements to test case assertions.
    • Refined test logic for ChatRoom and ManageTag components.
  • Code Quality

    • Improved code clarity by removing unnecessary comments in various components.
    • Enhanced localStorage usage script output formatting.
  • Dependency Management

    • Updated project dependencies.
    • Removed unused testing libraries.

Suyash878 and others added 30 commits December 14, 2024 06:34
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Copy link
Contributor

coderabbitai bot commented Jan 5, 2025

Walkthrough

This pull request focuses on modernizing the project's linting and testing configurations. The changes include removing legacy ESLint configuration files (.eslintignore and .eslintrc.json), introducing a new eslint.config.mjs configuration, updating dependencies in package.json, and making minor adjustments to test configurations. The modifications aim to streamline the project's code quality checks and testing infrastructure, with a particular emphasis on migrating to a more modern ESLint flat configuration system.

Changes

File Change Summary
.eslintignore Deleted file that previously excluded certain paths from linting
.eslintrc.json Deleted legacy ESLint configuration file
eslint.config.mjs New ESLint flat configuration file added with comprehensive linting rules
package.json Updated dependencies, removed eslintConfig section, added new ESLint-related packages
src/GraphQl/Queries/fundQueries.ts Added USER_FUND_CAMPAIGNS query with minor casing correction
src/components/CheckIn/tagTemplate.ts Minor modification by removing an unnecessary newline character
src/components/UserPortal/ChatRoom/ChatRoom.spec.tsx Updated test assertions for ChatRoom component
src/screens/ManageTag/ManageTag.spec.tsx Cleaned up mocking structure in test cases
src/screens/OrganizationDashboard/OrganizationDashboard.tsx Removed ESLint disable comments for clearer code
vitest.config.ts Updated test configuration to include .mjs files
scripts/githooks/check-localstorage-usage.js Minor formatting changes in console output messages
scripts/githooks/update-toc.js Removed a blank line for cleaner code

Possibly related PRs

  • Migrating from eslintrc.json to eslint.config.js #2660: The migration from .eslintrc.json to eslint.config.js is relevant as it involves changes to ESLint configuration, which is directly related to the changes made in the main PR regarding the deletion of the .eslintignore and .eslintrc.json files.
  • update the @mui/x-date-pickers #2439: The update of the @mui/x-date-pickers package in the package.json could be related since the main PR involves changes to the package.json file, although it does not directly connect to the linting changes.

Suggested reviewers

  • palisadoes

Poem

🐰 A Linter's Delight

With configs so bright and clean,
ESLint dances, a coding machine!
No more ignored paths in sight,
Our code now shines with pure delight!
Rabbit's rules, sharp and neat,
Make our project look so sweet! 🌟


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 43ae646 and 9acec1e.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (1)
  • package.json (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • package.json

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
🪧 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 generate docstrings to generate docstrings for this PR. (Beta)
  • @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.

Copy link

github-actions bot commented Jan 5, 2025

Our Pull Request Approval Process

Thanks for contributing!

Testing Your Code

Remember, your PRs won't be reviewed until these criteria are met:

  1. We don't merge PRs with poor code quality.
    1. Follow coding best practices such that CodeRabbit.ai approves your PR.
  2. We don't merge PRs with failed tests.
    1. When tests fail, click on the Details link to learn more.
    2. Write sufficient tests for your changes (CodeCov Patch Test). Your testing level must be better than the target threshold of the repository
    3. Tests may fail if you edit sensitive files. Ask to add the ignore-sensitive-files-pr label if the edits are necessary.
  3. We cannot merge PRs with conflicting files. These must be fixed.

Our policies make our code better.

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (2)
eslint.config.mjs (1)

26-27: Remove any placeholder or test commit comment.

Line comments like “//test commit” can be removed or replaced with a more detailed explanation once the testing is complete to keep the configuration file clean.

-//test commit
vitest.config.ts (1)

17-17: Including .mjs in test pattern.

By adding mjs to the test include pattern, you’ll run all .mjs test files under Vitest. If .mjs is seldom used for tests in this repository, you may want to keep it out to reduce scanning overhead. Otherwise, it’s an acceptable addition.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 574fd60 and bb8508e.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (10)
  • .eslintignore (0 hunks)
  • .eslintrc.json (0 hunks)
  • eslint.config.mjs (1 hunks)
  • package.json (2 hunks)
  • src/GraphQl/Queries/fundQueries.ts (0 hunks)
  • src/components/CheckIn/tagTemplate.ts (1 hunks)
  • src/components/UserPortal/ChatRoom/ChatRoom.spec.tsx (1 hunks)
  • src/screens/ManageTag/ManageTag.spec.tsx (0 hunks)
  • src/screens/OrganizationDashboard/OrganizationDashboard.tsx (0 hunks)
  • vitest.config.ts (1 hunks)
💤 Files with no reviewable changes (5)
  • .eslintignore
  • src/screens/OrganizationDashboard/OrganizationDashboard.tsx
  • src/GraphQl/Queries/fundQueries.ts
  • .eslintrc.json
  • src/screens/ManageTag/ManageTag.spec.tsx
✅ Files skipped from review due to trivial changes (1)
  • src/components/CheckIn/tagTemplate.ts
🧰 Additional context used
📓 Learnings (1)
vitest.config.ts (1)
Learnt from: MayankJha014
PR: PalisadoesFoundation/talawa-admin#2619
File: vitest.config.ts:0-0
Timestamp: 2024-12-09T15:54:04.872Z
Learning: The files `scripts/custom-test-env.js`, `src/utils/i18nForTest.ts`, and `vitest.setup.ts` are not test files and should not be included in the test pattern.
🔇 Additional comments (8)
eslint.config.mjs (3)

1-14: Good use of ESLint plugins and configurations.

Importing a wide array of ESLint plugins (React, TypeScript, Jest, etc.) here is a solid starting point to enforce consistent style and best practices across the codebase.


28-45: Review the ignored patterns carefully.

These ignore rules appear comprehensive. Confirm you actually want to exclude the specified JSON, docs, and package files from lint checks. If you require linting on certain config or doc files, consider removing them from the ignore list.


57-215: Extensive rule set ensures consistent coding standards.

This set of rules integrates React, Prettier, TypeScript, and more, which is beneficial. Just confirm that developers are aware of the strict TypeScript rules (e.g., no-inferrable-types, no-non-null-assertion) to avoid frustration and frequent overrides.

src/components/UserPortal/ChatRoom/ChatRoom.spec.tsx (1)

5777-5778: Double-check the usage of waitFor with queryByTestId.

Using queryByTestId within waitFor typically works, but you may find findByTestId simpler if you want to wait for the element to appear. queryByTestId doesn’t throw if the element is missing, so ensure it matches your use case.

package.json (4)

114-114: New dependency @eslint/compat.

This ensures compatibility with older ESLint configs. Confirm you’re using it properly (e.g., your new eslint.config.mjs references fixupPluginRules, but consider hooking in FlatCompat usage if needed).


119-119: Added type definition for ESLint config.

Good addition for TypeScript support around ESLint configurations. This can help prevent type mismatches when dealing with ESLint rule sets.


139-139: Upgrading ESLint to ^9.10.0.

This upgrade offers newer ECMAScript support and rule enhancements. Just ensure no plugin version conflicts and that the new ESLint engine is compatible with your existing rules.


146-146: globals dependency added.

This usage can unify recognized browser/node global variables across the project. Check that you configure them consistently with the environment property in the ESLint config if needed.

Comment on lines +47 to +55
...compat.extends(
'plugin:react/recommended',
'eslint:recommended',
'plugin:jest/recommended',
'plugin:prettier/recommended',
'plugin:@typescript-eslint/recommended',
'eslint-config-prettier',
'prettier',
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Undefined variable compat.

The spread syntax ...compat.extends calls a compat variable that is not declared in this scope. Possibly you meant to instantiate compat from the createESLintCompat() function. Otherwise, this will raise a ReferenceError.

+const compat = createESLintCompat(); // Example usage
 export default [
   ...compat.extends(
     ...
   ),
   ...
 ];

Committable suggestion skipped: line range outside the PR's diff.

Comment on lines +15 to +24
export function createESLintCompat() {
const _filename = fileURLToPath(import.meta.url);
const _dirname = path.dirname(_filename);

return new FlatCompat({
baseDirectory: _dirname,
recommendedConfig: js.configs.recommended,
allConfig: js.configs.all,
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

The createESLintCompat() function is defined but not used, and there's an undefined compat variable being used

Looking at the complete file content, I found:

  1. The createESLintCompat() function is exported but never used within the file
  2. There's an undefined compat variable being used in the configuration (in ...compat.extends())

It appears that the intention was to use the createESLintCompat() function to create the compat instance, but this step was missed. The code should be fixed by adding:

const compat = createESLintCompat();

before using compat.extends().

🔗 Analysis chain

Check if createESLintCompat() is invoked or referenced.

The createESLintCompat() function is exported but never called within this file. If you intend to use its returned FlatCompat instance, ensure you do something like:

const compat = createESLintCompat();

Otherwise, remove the unused function.


Let me search for references to createESLintCompat in the codebase.


Let me check the actual usage of createESLintCompat in the file to see if it's being used beyond just its definition.

🏁 Scripts executed

The following scripts were executed for the analysis:

Error: No shell scripts found


Script:

#!/bin/bash
# Search for references to createESLintCompat
rg "createESLintCompat" -l

Length of output: 44


Script:

#!/bin/bash
# Show the complete content of eslint.config.mjs to see if createESLintCompat is used
cat eslint.config.mjs

Length of output: 5425

@palisadoes
Copy link
Contributor

Please fix the conflicting file

@Suyash878
Copy link
Contributor Author

image
Apology for the inconvenience:
In eslint.config.mjs I think during adding suggestions from coderabbitai this line "export default [" was added, it just needs to be removed. So that the checks run on the test branch.

@palisadoes
Copy link
Contributor

  1. Update it in this PR
  2. We need to fix this quickly

@palisadoes
Copy link
Contributor

I reverted your previous PR. Please fix this one

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (2)
eslint.config.mjs (2)

136-142: Consider relaxing interface naming convention.

The current configuration requires all interfaces to have either 'Interface' or 'TestInterface' as a prefix. This might be overly restrictive and goes against common TypeScript conventions where interfaces typically don't require specific prefixes.

Consider modifying the rule to allow standard PascalCase without prefixes:

       {
         selector: 'interface',
         format: ['PascalCase'],
-        prefix: ['Interface', 'TestInterface'],
       },

30-45: Consider using .gitignore patterns for better maintainability.

The ignore patterns could potentially overlap with .gitignore. Consider using eslint-ignore-path to reuse .gitignore patterns where applicable, reducing maintenance overhead.

🧰 Tools
🪛 eslint

[error] 44-44: Insert ,

(prettier/prettier)

🪛 GitHub Check: Performs linting, formatting, type-checking, checking for different source and target branch

[failure] 44-44:
Insert ,

🪛 GitHub Actions: PR Workflow

[error] 44-44: Missing comma. Prettier formatting rule violation at position 18.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb8508e and 869dad5.

📒 Files selected for processing (1)
  • eslint.config.mjs (1 hunks)
🧰 Additional context used
🪛 eslint
eslint.config.mjs

[error] 44-44: Insert ,

(prettier/prettier)

🪛 GitHub Check: Performs linting, formatting, type-checking, checking for different source and target branch
eslint.config.mjs

[failure] 44-44:
Insert ,

🪛 GitHub Actions: PR Workflow
eslint.config.mjs

[error] 44-44: Missing comma. Prettier formatting rule violation at position 18.

🔇 Additional comments (2)
eslint.config.mjs (2)

1-14: LGTM! All necessary ESLint dependencies are properly imported.

The import statements are well-organized and include all required plugins and utilities for the ESLint configuration.


15-27: LGTM! Helper function and initialization are properly implemented.

The createESLintCompat function is well-implemented and the compat instance is correctly initialized. This resolves the issues mentioned in previous review comments.

'**/package.json',
'**/package-lock.json',
'**/tsconfig.json',
'docs/**/*'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix: Add missing comma in ignore patterns list.

Add a comma after 'docs/**/*' to fix the syntax error and resolve the pipeline failure.

      'docs/**/*'
+     ,
📝 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
'docs/**/*'
'docs/**/*',
🧰 Tools
🪛 eslint

[error] 44-44: Insert ,

(prettier/prettier)

🪛 GitHub Check: Performs linting, formatting, type-checking, checking for different source and target branch

[failure] 44-44:
Insert ,

🪛 GitHub Actions: PR Workflow

[error] 44-44: Missing comma. Prettier formatting rule violation at position 18.

Comment on lines +91 to +125
rules: {
'react/destructuring-assignment': 'error',
'@typescript-eslint/explicit-module-boundary-types': 'error',

'react/no-multi-comp': [
'error',
{
ignoreStateless: false,
},
],

'react/jsx-filename-extension': [
'error',
{
extensions: ['.tsx'],
},
],

'import/no-duplicates': 'error',
'tsdoc/syntax': 'error',
'@typescript-eslint/ban-ts-comment': 'error',
'@typescript-eslint/no-unused-vars': 'error',
'@typescript-eslint/no-explicit-any': 'error',
'@typescript-eslint/no-inferrable-types': 'error',
'@typescript-eslint/no-non-null-asserted-optional-chain': 'error',
'@typescript-eslint/no-non-null-assertion': 'error',
'@typescript-eslint/no-var-requires': 'error',
'@typescript-eslint/no-unsafe-function-type': 'error',
'@typescript-eslint/no-wrapper-object-types': 'error',
'@typescript-eslint/no-empty-object-type': 'error',
'@typescript-eslint/no-duplicate-enum-values': 'error',
'@typescript-eslint/array-type': 'error',
'@typescript-eslint/consistent-type-assertions': 'error',
'@typescript-eslint/consistent-type-imports': 'error',

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Consider relaxing TypeScript rules based on codebase analysis

Based on the codebase analysis:

  1. The no-explicit-any rule should be relaxed to warn as there are several legitimate uses of any in utility functions and state management:

    • Helper functions in useLocalstorage.ts
    • Redux action creators and reducers
    • Plugin management utilities
  2. The no-non-null-assertion rule can remain as error since most ! occurrences in the codebase are in:

    • CSS files (for !important)
    • Logical negations in conditionals
    • No actual non-null assertions found
  3. The consistent-type-imports rule can remain as error since no type-only imports were found, suggesting the codebase already follows a consistent import style.

🔗 Analysis chain

Review strict TypeScript rules for potential impact.

The configuration enables several strict TypeScript rules that might impact development velocity:

  • no-explicit-any
  • no-non-null-assertion
  • consistent-type-imports

While these rules promote type safety, consider if they align with your team's development practices and whether some could be relaxed to warn instead of error.

Run this script to check current usage patterns that might be affected:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for patterns that would violate these strict rules
echo "Checking for 'any' type usage..."
rg ":\s*any\b" --type typescript

echo "Checking for non-null assertions..."
rg "!\b" --type typescript

echo "Checking for type import consistency..."
rg "import.*\{.*\}\s+from" --type typescript

Length of output: 466


Script:

#!/bin/bash
# Check for patterns that would violate these strict rules
echo "Checking for 'any' type usage..."
rg ":\s*any\b" -t ts -t tsx

echo "Checking for non-null assertions..."
rg "!\b" -t ts -t tsx

echo "Checking for type import consistency..."
rg "import.*\{.*\}\s+from" -t ts -t tsx

# Also check for .ts and .tsx files to confirm TypeScript usage
echo "Checking TypeScript files in the project..."
fd "\.(ts|tsx)$"

Length of output: 27995


Script:

#!/bin/bash
# Search for patterns without file type filtering since ripgrep's typescript detection isn't working
echo "Checking for 'any' type usage..."
rg ":\s*any\b"

echo "Checking for non-null assertions..."
rg "!\b"

echo "Checking for type import consistency..."
rg "^import\s+type\s*\{.*\}\s+from|^import\s*\{\s*type\s"

Length of output: 92867

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (3)
eslint.config.mjs (3)

1-14: Consider organizing imports for better maintainability.

Consider grouping imports into these categories for better organization:

  1. Built-in Node.js modules
  2. ESLint core and compatibility packages
  3. ESLint plugins
  4. Other external packages
+// Node.js built-in modules
 import path from 'node:path';
 import { fileURLToPath } from 'node:url';
+
+// ESLint core and compatibility
 import js from '@eslint/js';
 import { FlatCompat } from '@eslint/eslintrc';
 import { fixupPluginRules } from '@eslint/compat';
+
+// ESLint plugins
 import react from 'eslint-plugin-react';
 import typescriptEslint from '@typescript-eslint/eslint-plugin';
 import jest from 'eslint-plugin-jest';
 import _import from 'eslint-plugin-import';
 import tsdoc from 'eslint-plugin-tsdoc';
 import prettier from 'eslint-plugin-prettier';
+
+// Other packages
 import globals from 'globals';
 import tsParser from '@typescript-eslint/parser';

30-45: Optimize ignore patterns to reduce redundancy.

There are several opportunities to optimize the ignore patterns:

  1. Remove redundant 'docs/**/*' as it's already covered by more specific patterns
  2. Consider combining similar patterns
 ignores: [
-  '**/*.css',
-  '**/*.scss',
-  '**/*.less',
+  '**/*.{css,scss,less}',
   '**/*.json',
   '**/*.svg',
   'docs/docusaurus.config.ts',
   'docs/sidebars.ts',
   'docs/src/**/*',
   'docs/blog/**/*',
   'src/components/CheckIn/tagTemplate.ts',
-  '**/package.json',
-  '**/package-lock.json',
-  '**/tsconfig.json',
+  '**/{package,package-lock,tsconfig}.json',
-  'docs/**/*', // Remove redundant pattern
 ],

179-205: Strengthen React component conventions.

Consider these improvements to React-specific rules:

  1. Enable component definition style enforcement
  2. Consider stricter nested component rules
       'react/function-component-definition': [
-        0,
+        'error',
         {
-          namedComponents: 'function-declaration',
+          namedComponents: ['function-declaration', 'arrow-function'],
+          unnamedComponents: 'arrow-function'
         },
       ],
       
       'react/no-unstable-nested-components': [
         'error',
         {
-          allowAsProps: true,
+          allowAsProps: false,
         },
       ],

This change:

  1. Enforces consistent component definition styles
  2. Prevents potential performance issues with nested components
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 869dad5 and 8bf66f3.

📒 Files selected for processing (3)
  • eslint.config.mjs (1 hunks)
  • scripts/githooks/check-localstorage-usage.js (1 hunks)
  • scripts/githooks/update-toc.js (0 hunks)
💤 Files with no reviewable changes (1)
  • scripts/githooks/update-toc.js
✅ Files skipped from review due to trivial changes (1)
  • scripts/githooks/check-localstorage-usage.js
🔇 Additional comments (2)
eslint.config.mjs (2)

15-26: LGTM! Well-implemented ESM compatibility setup.

The createESLintCompat function correctly handles ESM module paths and properly initializes the FlatCompat instance.


91-125: Consider a more balanced TypeScript configuration.

The current configuration is very strict with all rules set to 'error'. Based on common practices and previous feedback:

-      '@typescript-eslint/no-explicit-any': 'error',
+      '@typescript-eslint/no-explicit-any': 'warn',
       '@typescript-eslint/no-inferrable-types': 'error',
       '@typescript-eslint/no-non-null-asserted-optional-chain': 'error',
-      '@typescript-eslint/no-non-null-assertion': 'error',
+      '@typescript-eslint/no-non-null-assertion': 'warn',

This adjustment:

  1. Relaxes no-explicit-any to allow for legitimate use cases in utilities and state management
  2. Reduces no-non-null-assertion severity while maintaining the warning

Comment on lines +136 to +177
'@typescript-eslint/naming-convention': [
'error',
{
selector: 'interface',
format: ['PascalCase'],
prefix: ['Interface', 'TestInterface'],
},
{
selector: ['typeAlias', 'typeLike', 'enum'],
format: ['PascalCase'],
},
{
selector: 'typeParameter',
format: ['PascalCase'],
prefix: ['T'],
},
{
selector: 'variable',
format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
leadingUnderscore: 'allow',
},
{
selector: 'parameter',
format: ['camelCase'],
leadingUnderscore: 'allow',
},
{
selector: 'function',
format: ['camelCase', 'PascalCase'],
},
{
selector: 'memberLike',
modifiers: ['private'],
format: ['camelCase'],
leadingUnderscore: 'require',
},
{
selector: 'variable',
modifiers: ['exported'],
format: null,
},
],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Revise naming conventions to align with common practices.

Two concerns with the current naming conventions:

  1. Requiring Interface/TestInterface prefix for interfaces goes against TypeScript best practices
  2. Having no format for exported variables (format: null) could lead to inconsistent naming
       {
         selector: 'interface',
         format: ['PascalCase'],
-        prefix: ['Interface', 'TestInterface'],
       },
       {
         selector: 'variable',
         modifiers: ['exported'],
-        format: null,
+        format: ['camelCase', 'PascalCase', 'UPPER_CASE'],
       },
📝 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
'@typescript-eslint/naming-convention': [
'error',
{
selector: 'interface',
format: ['PascalCase'],
prefix: ['Interface', 'TestInterface'],
},
{
selector: ['typeAlias', 'typeLike', 'enum'],
format: ['PascalCase'],
},
{
selector: 'typeParameter',
format: ['PascalCase'],
prefix: ['T'],
},
{
selector: 'variable',
format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
leadingUnderscore: 'allow',
},
{
selector: 'parameter',
format: ['camelCase'],
leadingUnderscore: 'allow',
},
{
selector: 'function',
format: ['camelCase', 'PascalCase'],
},
{
selector: 'memberLike',
modifiers: ['private'],
format: ['camelCase'],
leadingUnderscore: 'require',
},
{
selector: 'variable',
modifiers: ['exported'],
format: null,
},
],
'@typescript-eslint/naming-convention': [
'error',
{
selector: 'interface',
format: ['PascalCase'],
},
{
selector: ['typeAlias', 'typeLike', 'enum'],
format: ['PascalCase'],
},
{
selector: 'typeParameter',
format: ['PascalCase'],
prefix: ['T'],
},
{
selector: 'variable',
format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
leadingUnderscore: 'allow',
},
{
selector: 'parameter',
format: ['camelCase'],
leadingUnderscore: 'allow',
},
{
selector: 'function',
format: ['camelCase', 'PascalCase'],
},
{
selector: 'memberLike',
modifiers: ['private'],
format: ['camelCase'],
leadingUnderscore: 'require',
},
{
selector: 'variable',
modifiers: ['exported'],
format: ['camelCase', 'PascalCase', 'UPPER_CASE'],
},
],

@Suyash878 Suyash878 changed the title Test PR to check if workflows. Test PR to check if workflows break. Jan 5, 2025
@palisadoes palisadoes added the ignore-sensitive-files-pr The contributor has a legitimate reason for editiing protected files label Jan 5, 2025
@palisadoes
Copy link
Contributor

  1. Please fix the failing tests
  2. The sensitive file test will be ignored on your next commit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ignore-sensitive-files-pr The contributor has a legitimate reason for editiing protected files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants