📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{js,ts,jsx,tsx}: Always wrap while and for loop bodies in braces {}.
Do not use single-line loop bodies without braces.
Default: wrap if bodies in braces {}, with allowed single-line exceptions only for early-exit statements (if (cond) continue;, if (cond) break;, if (cond) return;, or if (cond) return <primitive>;).
Prefer early returns to reduce nesting. For multiple early exits, write one if per line instead of combining with || for early exits.
Multi-line comments should wrap at 80 characters.
Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).
Place comments above the code they describe, not at the end of the line.
Use JSDoc for functions, parameters, and types when documenting top-level functions, APIs, or non-obvious behavior.
If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.
If the comment is not JSDoc, it should start with //. If it's multi-line comment, each line should start with //.
Use the function keyword for module-level/top-level functions.
Inside functions, declare nested helpers with const and arrow syntax (e.g., const helper = () => { ... };).
Avoid deep nesting; prefer early returns and small helpers.
Avoid abbreviated variable names except for conventional indices i, j, k. Use descriptive, intention-revealing names.
When indexing arrays, guard against undefined. Do not use non-null assertions with indexed access. Check with if (!item) or if (item == null) before using the indexed element.
Eliminate repetition by extracting shared logic into small, well-named functions.
Choose function names that convey intent so readers rarely need comments to understand WHAT a function does.
Keep complex conditions readable; prefer early returns or well-named variables to long boolean chains.
Maintain the existing indentation style and width of any file you edit.

Files:

• examples/menu-nested/test.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{ts,tsx}: Type assertions and casts in TypeScript: Use safe, explicit operators that preserve type intent. Allowed: as const for narrowing literals, DOM-specific casts with runtime checks, and satisfies for validation. Disallowed: as any and unknown as T to silence errors. Prefer proper typing with generics, discriminated unions, and type guards.
Prefer interface over type for object shapes. Use type only when interfaces cannot express the shape (unions, tuples, conditional or mapped types).

Files:

• examples/menu-nested/test.ts

Learnt from: CR
Repo: ariakit/ariakit PR: 0
File: .cursor/rules/style.mdc:0-0
Timestamp: 2025-11-24T22:53:38.597Z
Learning: Applies to **/*.{js,ts,jsx,tsx} : Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).

Applied to files:

• examples/menu-nested/test.ts

Learnt from: CR
Repo: ariakit/ariakit PR: 0
File: .cursor/rules/style.mdc:0-0
Timestamp: 2025-11-24T22:53:38.597Z
Learning: Applies to **/*.{js,ts,jsx,tsx} : If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.

Applied to files:

• examples/menu-nested/test.ts

Learnt from: CR
Repo: ariakit/ariakit PR: 0
File: .cursor/rules/style.mdc:0-0
Timestamp: 2025-11-24T22:53:38.597Z
Learning: Applies to **/*.{js,ts,jsx,tsx} : Place comments above the code they describe, not at the end of the line.

Applied to files:

• examples/menu-nested/test.ts

packages/ariakit-test/src/click.ts (1)

• click (128-169)

packages/ariakit-test/src/query.ts (1)

• q (165-165)

packages/ariakit-test/src/hover.ts (1)

• hover (15-73)

[grammar] ~273-~273: Ensure spelling is correct
Context: ... between commits and frameworks. We use exising tests to create benchmarks via `vitest-...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{js,ts,jsx,tsx}: Always wrap while and for loop bodies in braces {}.
Do not use single-line loop bodies without braces.
Default: wrap if bodies in braces {}, with allowed single-line exceptions only for early-exit statements (if (cond) continue;, if (cond) break;, if (cond) return;, or if (cond) return <primitive>;).
Prefer early returns to reduce nesting. For multiple early exits, write one if per line instead of combining with || for early exits.
Multi-line comments should wrap at 80 characters.
Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).
Place comments above the code they describe, not at the end of the line.
Use JSDoc for functions, parameters, and types when documenting top-level functions, APIs, or non-obvious behavior.
If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.
If the comment is not JSDoc, it should start with //. If it's multi-line comment, each line should start with //.
Use the function keyword for module-level/top-level functions.
Inside functions, declare nested helpers with const and arrow syntax (e.g., const helper = () => { ... };).
Avoid deep nesting; prefer early returns and small helpers.
Avoid abbreviated variable names except for conventional indices i, j, k. Use descriptive, intention-revealing names.
When indexing arrays, guard against undefined. Do not use non-null assertions with indexed access. Check with if (!item) or if (item == null) before using the indexed element.
Eliminate repetition by extracting shared logic into small, well-named functions.
Choose function names that convey intent so readers rarely need comments to understand WHAT a function does.
Keep complex conditions readable; prefer early returns or well-named variables to long boolean chains.
Maintain the existing indentation style and width of any file you edit.

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{ts,tsx}: Type assertions and casts in TypeScript: Use safe, explicit operators that preserve type intent. Allowed: as const for narrowing literals, DOM-specific casts with runtime checks, and satisfies for validation. Disallowed: as any and unknown as T to silence errors. Prefer proper typing with generics, discriminated unions, and type guards.
Prefer interface over type for object shapes. Use type only when interfaces cannot express the shape (unions, tuples, conditional or mapped types).

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{js,ts,jsx,tsx}: Always wrap while and for loop bodies in braces {}.
Do not use single-line loop bodies without braces.
Default: wrap if bodies in braces {}, with allowed single-line exceptions only for early-exit statements (if (cond) continue;, if (cond) break;, if (cond) return;, or if (cond) return <primitive>;).
Prefer early returns to reduce nesting. For multiple early exits, write one if per line instead of combining with || for early exits.
Multi-line comments should wrap at 80 characters.
Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).
Place comments above the code they describe, not at the end of the line.
Use JSDoc for functions, parameters, and types when documenting top-level functions, APIs, or non-obvious behavior.
If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.
If the comment is not JSDoc, it should start with //. If it's multi-line comment, each line should start with //.
Use the function keyword for module-level/top-level functions.
Inside functions, declare nested helpers with const and arrow syntax (e.g., const helper = () => { ... };).
Avoid deep nesting; prefer early returns and small helpers.
Avoid abbreviated variable names except for conventional indices i, j, k. Use descriptive, intention-revealing names.
When indexing arrays, guard against undefined. Do not use non-null assertions with indexed access. Check with if (!item) or if (item == null) before using the indexed element.
Eliminate repetition by extracting shared logic into small, well-named functions.
Choose function names that convey intent so readers rarely need comments to understand WHAT a function does.
Keep complex conditions readable; prefer early returns or well-named variables to long boolean chains.
Maintain the existing indentation style and width of any file you edit.

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{ts,tsx}: Type assertions and casts in TypeScript: Use safe, explicit operators that preserve type intent. Allowed: as const for narrowing literals, DOM-specific casts with runtime checks, and satisfies for validation. Disallowed: as any and unknown as T to silence errors. Prefer proper typing with generics, discriminated unions, and type guards.
Prefer interface over type for object shapes. Use type only when interfaces cannot express the shape (unions, tuples, conditional or mapped types).

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{js,ts,jsx,tsx}: Always wrap while and for loop bodies in braces {}.
Do not use single-line loop bodies without braces.
Default: wrap if bodies in braces {}, with allowed single-line exceptions only for early-exit statements (if (cond) continue;, if (cond) break;, if (cond) return;, or if (cond) return <primitive>;).
Prefer early returns to reduce nesting. For multiple early exits, write one if per line instead of combining with || for early exits.
Multi-line comments should wrap at 80 characters.
Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).
Place comments above the code they describe, not at the end of the line.
Use JSDoc for functions, parameters, and types when documenting top-level functions, APIs, or non-obvious behavior.
If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.
If the comment is not JSDoc, it should start with //. If it's multi-line comment, each line should start with //.
Use the function keyword for module-level/top-level functions.
Inside functions, declare nested helpers with const and arrow syntax (e.g., const helper = () => { ... };).
Avoid deep nesting; prefer early returns and small helpers.
Avoid abbreviated variable names except for conventional indices i, j, k. Use descriptive, intention-revealing names.
When indexing arrays, guard against undefined. Do not use non-null assertions with indexed access. Check with if (!item) or if (item == null) before using the indexed element.
Eliminate repetition by extracting shared logic into small, well-named functions.
Choose function names that convey intent so readers rarely need comments to understand WHAT a function does.
Keep complex conditions readable; prefer early returns or well-named variables to long boolean chains.
Maintain the existing indentation style and width of any file you edit.

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{ts,tsx}: Type assertions and casts in TypeScript: Use safe, explicit operators that preserve type intent. Allowed: as const for narrowing literals, DOM-specific casts with runtime checks, and satisfies for validation. Disallowed: as any and unknown as T to silence errors. Prefer proper typing with generics, discriminated unions, and type guards.
Prefer interface over type for object shapes. Use type only when interfaces cannot express the shape (unions, tuples, conditional or mapped types).

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{js,ts,jsx,tsx}: Always wrap while and for loop bodies in braces {}.
Do not use single-line loop bodies without braces.
Default: wrap if bodies in braces {}, with allowed single-line exceptions only for early-exit statements (if (cond) continue;, if (cond) break;, if (cond) return;, or if (cond) return <primitive>;).
Prefer early returns to reduce nesting. For multiple early exits, write one if per line instead of combining with || for early exits.
Multi-line comments should wrap at 80 characters.
Explain the WHY and HOW in comments, not the WHAT (the WHAT should be clear from good names).
Place comments above the code they describe, not at the end of the line.
Use JSDoc for functions, parameters, and types when documenting top-level functions, APIs, or non-obvious behavior.
If logic feels complex, extract a well-named helper that explains the WHAT; add a short rationale comment if useful.
If the comment is not JSDoc, it should start with //. If it's multi-line comment, each line should start with //.
Use the function keyword for module-level/top-level functions.
Inside functions, declare nested helpers with const and arrow syntax (e.g., const helper = () => { ... };).
Avoid deep nesting; prefer early returns and small helpers.
Avoid abbreviated variable names except for conventional indices i, j, k. Use descriptive, intention-revealing names.
When indexing arrays, guard against undefined. Do not use non-null assertions with indexed access. Check with if (!item) or if (item == null) before using the indexed element.
Eliminate repetition by extracting shared logic into small, well-named functions.
Choose function names that convey intent so readers rarely need comments to understand WHAT a function does.
Keep complex conditions readable; prefer early returns or well-named variables to long boolean chains.
Maintain the existing indentation style and width of any file you edit.

Files:

• vitest.config.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

**/*.{ts,tsx}: Type assertions and casts in TypeScript: Use safe, explicit operators that preserve type intent. Allowed: as const for narrowing literals, DOM-specific casts with runtime checks, and satisfies for validation. Disallowed: as any and unknown as T to silence errors. Prefer proper typing with generics, discriminated unions, and type guards.
Prefer interface over type for object shapes. Use type only when interfaces cannot express the shape (unions, tuples, conditional or mapped types).

Files:

• vitest.config.ts