diff --git a/.coderabbit.yaml b/.coderabbit.yaml index f69abfe..326235b 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -4,11 +4,10 @@ # Language for CodeRabbit's review comments language: en -# Enable experimental features (currently not using any specific early_access features) +# Enable experimental features early_access: true chat: - # CodeRabbit will automatically respond to @coderabbitai mentions in PR comments auto_reply: true issue_enrichment: @@ -16,76 +15,55 @@ issue_enrichment: auto_apply_labels: true labeling_instructions: - label: bug - instructions: Issues reporting bugs, errors, crashes, incorrect behavior, or unexpected results. This includes runtime errors, logic errors, broken functionality, regressions, and any deviation from expected or documented behavior. + instructions: Issues reporting bugs, crashes, incorrect behavior, regressions, or unexpected results. - label: enhancement - instructions: Feature requests, improvements to existing functionality, performance optimizations, refactoring suggestions, UI/UX enhancements, and any suggestions to make the project better or add new capabilities. + instructions: Feature requests, improvements, optimizations, refactoring suggestions, or new capabilities. - label: documentation - instructions: Documentation updates, additions, corrections, or clarifications needed. This includes missing docs, outdated information, unclear instructions, API documentation, code examples, README improvements, and any requests for better explanations or guides. + instructions: Documentation updates, corrections, missing docs, or README improvements. + planning: enabled: true auto_planning: enabled: true labels: - - "plan-me" # Auto-plan issues with this label - - "feature" # Also auto-plan these - - "!no-plan" # Never auto-plan issues with this label + - "plan-me" + - "feature" + - "!no-plan" reviews: - profile: assertive # Options: chill (focuses on significant issues, less nitpicky about style), assertive (more thorough, flags style issues and minor improvements too) + profile: assertive auto_review: - # Automatically trigger reviews when PRs are opened or updated enabled: true - # Skip auto-review if PR title contains these keywords ignore_title_keywords: - "WIP" - # Don't auto-review draft PRs drafts: false - # Only auto-review PRs targeting these branches base_branches: - main - develop - # Include a high-level summary at the start of each review high_level_summary: true - - # Generate sequence diagrams for complex code flows sequence_diagrams: true - - # Include poems in reviews poem: true - - # Show review completion status review_status: true - - # Keep the walkthrough section expanded by default collapse_walkthrough: false - - # Include summary of all changed files changed_files_summary: true - - # Automatically request changes on the PR (just leave comments) request_changes_workflow: true - # Pre-merge checks to enforce before merging PRs pre_merge_checks: description: - # Validate that PR has a proper description - mode: warning # Options: off, warning, error + mode: warning docstrings: - # Disable docstring coverage checks (let's assume we don't need them) mode: off - # Exclude these paths from reviews (build artifacts and dependencies) path_filters: - - "!**/node_modules/**" # npm dependencies - - "!**/android/**" # Native Android build files - - "!**/ios/**" # Native iOS build files - - "!**/.expo/**" # Expo build cache - - "!**/.expo-shared/**" # Expo shared config - - "!**/dist/**" # Build output + - "!**/node_modules/**" + - "!**/android/**" + - "!**/ios/**" + - "!**/.expo/**" + - "!**/.expo-shared/**" + - "!**/dist/**" - # Use the following tools when reviewing tools: shellcheck: enabled: true @@ -122,159 +100,101 @@ reviews: eslint: enabled: true - # Apply the following labels to PRs labeling_instructions: - label: Python Lang - instructions: Apply when the PR/MR contains changes to python source-code + instructions: Apply when the PR contains Python source code changes - label: Solidity Lang - instructions: Apply when the PR/MR contains changes to solidity source-code + instructions: Apply when the PR contains Solidity source code changes - label: Typescript Lang - instructions: Apply when the PR/MR contains changes to javascript or typescript source-code + instructions: Apply when the PR contains JavaScript or TypeScript code - label: Ergoscript Lang - instructions: Apply when the PR/MR contains changes to ergoscript source-code + instructions: Apply when the PR contains ErgoScript code - label: Bash Lang - instructions: >- - Apply when the PR/MR contains changes to shell-scripts or BASH code - snippets + instructions: Apply when the PR contains shell scripts or Bash code - label: Make Lang - instructions: >- - Apply when the PR/MR contains changes to the file `Makefile` or makefile - code snippets + instructions: Apply when the PR modifies Makefile - label: Documentation - instructions: >- - Apply whenever project documentation (namely markdown source-code) is - updated by the PR/MR + instructions: Apply when Markdown documentation is updated - label: Linter - instructions: >- - Apply when the purpose of the PR/MR is related to fixing the feedback - from a linter + instructions: Apply when PR fixes linter feedback - # Review instructions that apply to all files instructions: >- - - Verify that documentation and comments are free of spelling mistakes - - Ensure that test code is automated, comprehensive, and follows testing best practices - - Verify that all critical functionality is covered by tests - - Confirm that the code meets the project's requirements and objectives - - Confirm that copyright years are up-to date whenever a file is changed - - Point out redundant obvious comments that do not add clarity to the code - - Ensure that comments are concise and suggest more concise comment statements if possible - - Discourage usage of verbose comment styles such as NatSpec - - Look for code duplication - - Suggest code completions when: - - seeing a TODO comment - - seeing a FIXME comment + - Verify documentation and comments have no spelling mistakes + - Ensure automated tests exist and are comprehensive + - Confirm critical functionality is covered by tests + - Confirm the code meets project requirements + - Ensure copyright years are updated + - Identify redundant comments + - Ensure comments remain concise + - Discourage verbose comment styles such as NatSpec + - Detect duplicated code + - Suggest improvements for TODO or FIXME comments - # Custom review instructions for specific file patterns path_instructions: - # TypeScript/JavaScript files + + - path: "**/*.go" + instructions: | + Go code review guidelines: + + **Naming & Style** + - Follow Effective Go naming conventions. + - Package names should be lowercase and descriptive. + - Exported functions and types should include godoc comments. + + **Error Handling** + - Errors should not be ignored. + - Prefer wrapping errors using fmt.Errorf("...: %w", err). + + **Testing** + - Prefer table-driven tests where appropriate. + - Ensure exported functions have tests when applicable. + - path: "**/*.{ts,tsx,js,jsx}" instructions: | NextJS: - - Ensure that "use client" is being used - - Ensure that only features that allow pure client-side rendering are used - - NextJS best practices (including file structure, API routes, and static generation methods) are used. - + - Ensure "use client" is used when required + - Follow NextJS best practices + TypeScript: - - Avoid 'any', use explicit types - - Prefer 'import type' for type imports - - Review for significant deviations from Google JavaScript style guide. Minor style issues are not a priority - - The code adheres to best practices associated with React - - The code adheres to best practices associated with React PWA - - The code adheres to best practices associated with SPA - - The code adheres to best practices recommended by lighthouse or similar tools for performance - - The code adheres to best practices associated with Node.js - - The code adheres to best practices recommended for performance + - Avoid `any` + - Prefer `import type` + - Follow React and Node.js best practices Security: - - No exposed API keys or sensitive data - - Use expo-secure-store for sensitive storage - - Validate deep linking configurations - - Check for common security vulnerabilities such as: - - SQL Injection - - XSS (Cross-Site Scripting) - - CSRF (Cross-Site Request Forgery) - - Insecure dependencies - - Sensitive data exposure + - No exposed API keys + - Check for SQL Injection, XSS, CSRF + - Avoid insecure dependencies Internationalization: - - User-visible strings should be externalized to resource files (i18n) + - Externalize user-visible strings (i18n) - # HTML files - path: "**/*.html" instructions: | - Review the HTML code against the google html style guide and point out any mismatches. Ensure that: - - The code adheres to best practices recommended by lighthouse or similar tools for performance + Review HTML against Google HTML style guide. + Ensure Lighthouse performance best practices. - # CSS files - path: "**/*.css" instructions: | - Review the CSS code against the google css style guide and point out any mismatches. Ensure that: - - The code adheres to best practices associated with CSS. - - The code adheres to best practices recommended by lighthouse or similar tools for performance. - - The code adheres to similar naming conventions for classes, ids. + Review CSS against Google CSS style guide. + Ensure Lighthouse performance best practices. - # Python files - - path: "**/*.{py}" + - path: "**/*.py" instructions: | - Python: - - Check for major PEP 8 violations and Python best practices. + Check major PEP8 violations and Python best practices. - # Solidity Smart Contract files - path: "**/*.sol" instructions: | - Solidity: - - Review the Solidity contracts for security vulnerabilities and adherence to best practices. - - Ensure immutability is used appropriately (e.g., `immutable` and `constant` where applicable). - - Ensure there are no unbounded loops that could lead to gas exhaustion. - - Verify correct and explicit visibility modifiers for all state variables and functions. - - Flag variables that are declared but used only once or are unnecessary. - - Identify potential gas optimization opportunities without compromising readability or security. - - Verify that any modification to contract logic includes corresponding updates to automated tests. - - Ensure failure paths and revert scenarios are explicitly handled and validated. - - Validate proper access control enforcement (e.g., Ownable, RBAC, role checks). - - Ensure consistent and correct event emission for all state-changing operations. - - Confirm architectural consistency with existing contracts (no unintended storage layout changes unless clearly documented). - - Flag major feature additions or architectural changes that were implemented without prior design discussion (if applicable). - - Flag pull requests that mix unrelated changes or multiple concerns in a single submission. - - Ensure security-sensitive logic changes are not introduced without adequate test coverage. - - Review for common smart contract vulnerabilities, including but not limited to: - - Reentrancy - - Improper input validation - - Access control bypass - - Integer overflows/underflows (if using unchecked blocks) - - Front-running risks where applicable + Review Solidity contracts for security vulnerabilities. + Verify access control, event emission, and storage layout consistency. - - # Javascript/Typescript test files - path: "**/*.test.{ts,tsx,js,jsx}" instructions: | - Review test files for: - - Comprehensive coverage of component behavior - - Proper use of @testing-library/react-native - - Async behavior is properly tested - - Accessibility testing is included - - Test descriptions are sufficiently detailed to clarify the purpose of each test - - The tests are not tautological + Review test files for coverage, async behavior, and clear test descriptions. - # Solidity test files - path: "**/*.test.{sol}" instructions: | - Review test files for: - - Comprehensive coverage of contract behavior. - - Coverage of success paths, edge cases, and failure/revert scenarios. - - Proper validation of access control restrictions. - - Verification of event emissions where applicable. - - Explicit validation of state changes after each relevant function call. - - Adequate test updates whenever contract logic is modified. - - Deterministic behavior (tests should not rely on implicit execution order or shared mutable state). - - Clear and descriptive test names that reflect the intended behavior being validated. - + Ensure Solidity tests cover success paths, edge cases, and revert scenarios. - # Asset files (images, fonts, etc.) - path: "assets/**/*" instructions: | - Review asset files for: - - Image optimization (appropriate size and format) - - Proper @2x and @3x variants for different screen densities - - SVG assets are optimized - - Font files are licensed and optimized + Review assets for optimization, proper resolution variants, and licensing. \ No newline at end of file