📄 CodeRabbit Inference Engine (.cursorrules)

**/*.{js,jsx,ts,tsx}: Don’t use null inside the app, only on code interacting with external interfaces/services, like DB and HTTP; convert to undefined before sending inwards into the code
Use const whenever possible
Use async/await instead of .then()
Naming: classes, enums: PascalCase
Naming: constants, variables, functions: camelCase
Naming: file names: kebab-case
Naming: Don’t use negative names, like notEnabled, prefer isDisabled
If possible, use decomposing objects for function parameters
Prefer Nullish Coalesce (??) than the OR operator (||) when you want to provide a default value
Avoid creating arrow functions
Use truthy syntax instead of in - i.e., if (data.link) not if ('link' in data)
While handling errors, keep the stack trace around: if you create a new Error (e.g., MetriportError), make sure to pass the original error as the new one’s cause so the stack trace is available upstream.
max column length is 100 chars
multi-line comments use /** */
top-level comments go after the import (save pre-import to basic file header, like license)
move literals to constants declared after imports when possible

Files:

• packages/api/src/external/commonwell/document/document-query.ts

📄 CodeRabbit Inference Engine (.cursorrules)

Use types whenever possible

Files:

• packages/api/src/external/commonwell/document/document-query.ts

⚙️ CodeRabbit Configuration File

**/*.ts: - Use the Onion Pattern to organize a package's code in layers

• Try to use immutable code and avoid sharing state across different functions, objects, and systems
• Try to build code that's idempotent whenever possible
• Prefer functional programming style functions: small, deterministic, 1 input, 1 output
• Minimize coupling / dependencies
• Avoid modifying objects received as parameter
• Only add comments to code to explain why something was done, not how it works
• Naming
  • classes, enums: PascalCase
  • constants, variables, functions: camelCase
  • file names: kebab-case
  • table and column names: snake_case
  • Use meaningful names, so whoever is reading the code understands what it means
  • Don’t use negative names, like notEnabled, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to other types
  • Type predicates: only applicable to narrow down the type, not to force a complete type conversion
  • Prefer deconstructing parameters for functions instead of multiple parameters that might be of
    the same type
  • Don’t use null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead of .then()
  • Use the strict equality operator ===, don’t use abstract equality operator ==
  • When calling a Promise-returning function asynchronously (i.e., not awaiting), use .catch() to
    handle errors (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• Prefer Nullish Coalesce (??) than the OR operator (||) to provide a default value
• Avoid creating arrow functions
• U...

Files:

• packages/api/src/external/commonwell/document/document-query.ts