Path-based instructions

Covered in this guideAdd custom review instructions for specific file paths using glob patterns. Ideal for enforcing style guides by file types or directories.

Code guidelines

Create persistent coding standards and best practices that CodeRabbit learns from your codebase and applies consistently across reviews.

Learnings

Capture feedback from code review conversations to help CodeRabbit understand your team’s preferences and coding patterns.

​
Path-based instructions

Add custom code review instructions for your entire project or specific file paths using glob patterns. Developers can provide tailored review guidelines based on file paths.
Use path-based instructions when you want CodeRabbit to follow specific guidelines beyond standard reviews, such as enforcing style guides by file types or directories.

​
Default blocked paths

By default, CodeRabbit blocks certain file paths and extensions from being reviewed. If you want CodeRabbit to review any of these blocked paths, you can explicitly include them in your Path Filters configuration.

​
Configure path filters

You can edit your path filters directly in the UI:
1

Navigate to settings

Go to Configuration > Review > Settings > Path Filters
2

Modify filters

Add or remove path patterns as needed
Path Filters Configuration

​
Sample usage

Paths accept glob patterns. See the minimatch documentation for more information.
YAML
#...
reviews:
  #...
  path_instructions:
    - path: "**/*.js"
      instructions: |
        Review the JavaScript code against the Google JavaScript style guide and point out any mismatches
    - path: "tests/**.*"
      instructions: |
        Review the following unit test code written using the Mocha test library. Ensure that:
        - The code adheres to best practices associated with Mocha.
        - Descriptive test names are used to clearly convey the intent of each test.

​
Abstract Syntax Tree (AST) based instructions

This feature is available exclusively as part of the Pro plan and is not included in the Lite plan. Please refer to our pricing page for more information about our plans and features.
CodeRabbit offers review instructions based on Abstract Syntax Tree (AST) patterns. Under the hood, CodeRabbit uses ast-grep to power this feature.

ast-grep

ast-grep is written in Rust and uses the tree-sitter parser to generate the AST for popular languages. Written and maintained by Herrington Darkholme.
ast-grep Playground is quite effective in designing and testing AST rules on source code snippets. You can access the playground here.
The additional context provided by this feature is only available during the automated code review process, and it’s not available in the chat.Moreover, this feature is only recommended for advanced users as there is a learning curve involved.
Deep dive into AST patterns and ast-grep rules
This section explains how to add custom code review instructions using ast-grep rules for searching code using abstract syntax trees (AST) patterns.

​
Setup process

1

Create rules directory

Create a directory to keep all the ast-grep rules in your project directory
2

Add rule files

Add individual .yaml files for each ast-grep rule within the newly created directory
3

Configure rules

Ensure that each .yaml file contains the necessary ast-grep rule configurations
4

Add message property

Ensure that all rules contain a message property that will be used during the review process
5

Update configuration

Add the rules’ directory to the .coderabbit.yml file under tools.ast-grep configuration
6

Add packages (optional)

Optionally, add packages property to specify packages that should be installed before running the ast-grep tool
YAML
#...
reviews:
  #...
  tools:
    ast-grep:
      essential_rules: true # option to enable essential security rules
      rule_dirs:
        - "custom-name"
      packages:
        - "myorg/myawesomepackage" # custom package name following the format organization/repository
  #...

​
The rule object

Rule object is the core concept of ast-grep rule system and every other feature is built on top of it. Below is the full list of fields in a rule object. Every rule field is optional and can be omitted, but at least one field should be present in a rule. A node will match a rule if and only if it satisfies all fields in the rule object.
YAML
rule:
  # atomic rule
  pattern: "search.pattern"
  kind: "tree_sitter_node_kind"
  regex: "rust|regex"
  # relational rule
  inside: { pattern: "sub.rule" }
  has: { kind: "sub_rule" }
  follows: { regex: "can|use|any" }
  precedes: { kind: "multi_keys", pattern: "in.sub" }
  # composite rule
  all: [{ pattern: "match.all" }, { kind: "match_all" }]
  any: [{ pattern: "match.any" }, { kind: "match_any" }]
  not: { pattern: "not.this" }
  matches: "utility-rule"

​
Rule categories

The rule object fields can be categorized into three types:

Atomic Rule

The most basic rule that checks if AST nodes match

Relational Rule

Rules that check if a node is surrounded by another node

Composite Rule

Rules that combine sub-rules together using logical operators
These three categories of rules can be composed together to create more complex rules.
The rule object is inspired by CSS selectors but with more composability and expressiveness. Thinking about how selectors in CSS work can help you understand the rule object!
Read ast-grep > documentation for detailed guides.

​
Atomic rule

Atomic rule defines the most basic matching rule that determines whether one syntax node matches the rule or not. There are three kinds of atomic rule: pattern, kind and regex.
Official documentation guide on Atomic Rule

​
Relational rule

A relational rule defines the relationship between two syntax nodes. There are four kinds of relational rule: inside, has, follows and precedes. All four relational rules accept a sub-rule object as their value. The sub-rule will match the surrounding node, while the relational rule itself will match the target node.
Official documentation guide on Relational Rule
YAML
rule:
  pattern: await $PROMISE
  inside:
    kind: for_in_statement
    stopBy: end

​
Composite rule

A composite rule defines the logical relationship between multiple sub-rules. There are three kinds of composite rule: all, any and not. all The all rule matches if all sub-rules match.
YAML
rule:
  all:
    - pattern: console.log('Hello World');
    - kind: expression_statement
any any rule matches if any sub-rule matches.
YAML
rule:
  any:
    - pattern: var a = $A
    - pattern: const a = $A
    - pattern: let a = $A
not not applies negation to a sub-rule. It matches if the sub-rule does not match.
YAML
rule:
  pattern: console.log($GREETING)
  not:
    pattern: console.log('Hello World')
Official documentation guide on Composite Rule

​
Reusing rule as utility

ast-grep chooses to use YAML for rule representation. While this decision makes writing rules easier, it does impose some limitations on the rule authoring. One of the limitations is that rule objects cannot be reused.

​
Local utility rule

Local utility rules are defined in the utils field of the config file. Utils is a string-keyed dictionary. For example, the following config file defines a local utility rule is-literal:
YAML
utils:
  is-literal:
    any:
      - kind: string
      - kind: number
      - kind: boolean
rule:
  matches: is-literal

​
Global utility rule

Global utility rules are defined in a separate file. But they are available across all rule configurations in the project. To create global utility rules, you need to have the rules directory created on the root of your project and another utils directory inside the root of your project.
YAML
my-awesome-project   # project root
  |- rules           # rule directory
  | |- my-rule.yml
  |- utils           # utils directory
  | |- is-literal.yml
Also, you need to add the rules and utils directories to the .coderabbit.yml file under tools.ast-grep configuration. The rules can also be inside a package. If you have a package that contains rules, you can add the package name to the packages field in the .coderabbit.yml file.
YAML
#...
reviews:
  #...
  tools:
    ast-grep:
      essential_rules: true
      rule_dirs:
        - "rules"
      util_dirs:
        - "utils"
      packages:
        - "my-awesome-org/my-awesome-package" # public repository that contains ast-grep rules
  #...
YAML
# is-literal.yml
id: is-literal
language: TypeScript
rule:
  any:
    - kind: "false"
    - kind: undefined
    - kind: "null"
    - kind: "true"
    - kind: regex
    - kind: number
    - kind: string
Official documentation guide on Utility Rule

​
Packages

A package allows you to share rules across multiple projects. Essentially, a package is a collection of ast-grep rules.

Built-in packages

CodeRabbit provides packages you can use out of the box

Custom packages

Create your own packages and share them with your community or organization

​
CodeRabbit packages

ast-grep-essentials

Essential security rules packageBecause we value security, this package gets its own property in the .coderabbit.yml file for easier installation without overwriting existing configurations.
 To use a package, you need to add the package name to the packages field in the .coderabbit.yml file.
YAML
#...
reviews:
  #...
  tools:
    ast-grep:
      essential_rules: true
      packages: # list of packages to install, in future coderabbit will provide a set of packages, beside the essentials one.
        - "my-awesome-org/my-awesome-package" # custom package name following the format organization/repository
  #...

​
Using custom package

Let’s say that you have a public repository that contains ast-grep rules. You can add the package name to the packages field in the .coderabbit.yml file.

​
Package requirements

YAML
#...
reviews:
  #...
  tools:
    ast-grep:
      packages:
        - "my-awesome-org/my-awesome-package"
  #...

​
Multiple languages support

CodeRabbit supports multiple programming languages for defining ast-grep rules:

Web Technologies

  • JavaScript
  • TypeScript

Systems Languages

  • C
  • Rust
  • Golang

Enterprise Languages

  • Java
  • C#
  • Kotlin
  • Python

​
Language examples

Below are examples of ast-grep rules in different languages:

​
JavaScript

Importing files without an extension is not allowed
YAML
id: find-import-file
language: js
message: "Importing files without an extension is not allowed"
rule:
  regex: "/[^.]+[^/]$"
  kind: string_fragment
  any:
    - inside:
        stopBy: end
        kind: import_statement
    - inside:
        stopBy: end
        kind: call_expression
        has:
          field: function
          regex: "^import$"
No console.log allowed except console.error on the catch block
YAML
id: no-console-except-error
language: typescript
message: "No console.log allowed except console.error on the catch block"
rule:
  any:
    - pattern: console.error($$$)
      not:
        inside:
          kind: catch_clause
          stopBy: end
    - pattern: console.$METHOD($$$)
constraints:
  METHOD:
    regex: "log|debug|warn"

​
C

In C, there is no built-in support for object-oriented programming, but some programmers use structs and function pointers to simulate classes and methods. However, this style can have some drawbacks, such as:
  • Extra memory allocation and reallocation for the struct and the function pointer.
  • Indirection overhead when calling the function pointer.
A possible alternative is to use a plain function call with the struct pointer as the first argument.
YAML
id: method_receiver
language: c
rule:
  pattern: $R.$METHOD($$$ARGS)
transform:
  MAYBE_COMMA:
    replace:
      source: $$$ARGS
      replace: "^.+"
      by: ", "
fix: $METHOD(&$R$MAYBE_COMMA$$$ARGS)