.coderabbit.yaml

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

language: 'en-US'
early_access: false
tone_instructions: 'You are an expert code reviewer in TypeScript, JavaScript, NodeJS, and ElectronJS. You work in an enterprise software developer team, providing concise and clear code review advice. You only elaborate or provide detailed explanations when requested.'

knowledge_base:
  opt_out: false
  code_guidelines:
    enabled: true
    filePatterns:
      - '**/CODING_STANDARDS.md'

reviews:
  profile: 'chill'
  request_changes_workflow: false
  high_level_summary: true
  poem: true
  review_status: true
  collapse_walkthrough: false
  auto_review:
    enabled: true
    drafts: false
    base_branches: ['main', 'release/*']
  path_instructions:
    - path: '**/*'
      instructions: |
        Bruno is a cross-platform Electron desktop app that runs on macOS, Windows, and Linux. Ensure that all code is OS-agnostic:
        - File paths must use `path.join()` or `path.resolve()` instead of hardcoded `/` or `\\` separators
        - Never assume case-sensitive or case-insensitive filesystems
        - Use `os.homedir()`, `app.getPath()`, or environment-appropriate APIs instead of hardcoded paths like `/home/`, `C:\\Users\\`, or `~/`
        - Line endings should be handled consistently (be aware of CRLF vs LF issues)
        - Use `path.sep` or `path.posix`/`path.win32` when platform-specific separators are needed
        - Shell commands or child_process calls must account for platform differences (e.g., `which` vs `where`, `/bin/sh` vs `cmd.exe`)
        - File permissions (e.g., `fs.chmod`, `fs.access`) should account for Windows not supporting Unix-style permission bits
        - Avoid relying on Unix-only signals (e.g., `SIGKILL`) without Windows fallbacks
        - Use `os.tmpdir()` instead of hardcoding `/tmp`
        - Environment variable access should handle platform differences (e.g., `HOME` vs `USERPROFILE`)
    - path: 'packages/**/*.{js,jsx,ts,tsx}'
      instructions: |
        Some packages in this monorepo are being migrated to TypeScript incrementally, others are
        still plain JS by design. Before applying any of the guidance below, check whether the
        package the changed file belongs to (its `packages/<name>/package.json`) already lists
        `typescript` as a dependency or devDependency. If it does not, skip this guidance entirely
        for that file — do not suggest converting a package to TypeScript that hasn't opted in.

        A `typescript` entry in `package.json` alone isn't sufficient — also check for a real
        `tsconfig.json`, a build/type-check script that compiles or type-checks source (not just
        test config), and existing `.ts`/`.tsx` files under the package's source directory (not
        only under `tests/`). If `typescript` is present only for tests or tooling (e.g. `ts-node`
        for scripts, `ts-jest`, a `.d.ts`-only setup) and the package's actual build/runtime source
        is still JavaScript-only, treat it the same as a non-opted-in package and skip this
        guidance.

        For packages that do have `typescript` wired into their real build/runtime (not just tests
        or tooling):
        - If the PR adds a **new** file as `.js`/`.jsx`, flag it and suggest `.ts`/`.tsx` instead,
          unless the PR description gives a clear reason (e.g. it's deliberately a near-identical
          copy of an existing JS sibling for a diff-driven change).
        - If a PR renames an existing `.js`/`.jsx` file to `.ts`/`.tsx` **and** changes its logic
          in the same diff, flag it — conversions should be their own standalone, minimal-diff
          commit/PR (rename only), separate from behavioral changes.
        - When a file is converted to TypeScript, flag use of `any` used as a shortcut rather than
          a genuinely unknown/dynamic type — prefer modeling the real shape (reuse types from
          `@usebruno/schema-types` where applicable).
        - Do not ask for unrelated `.js` files to be converted as part of an unrelated PR — that
          contradicts an incremental, file-at-a-time migration approach.
    - path: 'tests/**/**.*'
      instructions: |
        Review the following e2e test code written using the Playwright test library. Ensure that:
        - Follow the guidance in `docs/playwright-testing-guide.md` - the canonical E2E guide (structure, fixtures, best practices).
        - For anything the guide above doesn't cover, follow standard Playwright and e2e automation best practices
        - Try to reduce usage of `page.waitForTimeout();` in code unless absolutely necessary and the locator cannot be found using existing `expect()` playwright calls
        - Avoid using `page.pause()` in code
        - Use locator variables for locators
        - Avoid using test.only
        - Use multiple assertions
        - Promote the use of `test.step` as much as possible so the generated reports are easier to read
        - Ensure that the `fixtures` like the collections are nested inside the `fixtures` folder 
          


          **Fixture Example***: Here's an example of possible fixture and test pair
          ```
          .
          ├── fixtures
          │   └── collection
          │       ├── base.bru
          │       ├── bruno.json
          │       ├── collection.bru
          │       ├── ws-test-request-with-headers.bru
          │       ├── ws-test-request-with-subproto.bru
          │       └── ws-test-request.bru
          ├── connection.spec.ts # <- Depends on the collection in ./fixtures/collection
          ├── headers.spec.ts
          ├── persistence.spec.ts
          ├── variable-interpolation
          │   ├── fixtures
          │   │   └── collection
          │   │       ├── environments
          │   │       ├── bruno.json
          │   │       └── ws-interpolation-test.bru
          │   ├── init-user-data
          │   └── variable-interpolation.spec.ts # <- Depends on the collection in ./variable-interpolation/fixtures/collection
          └── subproto.spec.ts
          ```

chat:
  auto_reply: true