📄 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/infra/lib/api-stack/api-service.ts
• packages/api/src/command/medical/document/__tests__/process-doc-query-webhook.test.ts
• packages/core/src/util/config.ts
• packages/infra/config/env-config.ts
• packages/api/src/shared/config.ts
• packages/api/src/routes/internal/ehr/canvas/setup.ts
• packages/api/src/command/internal-server/update-customer.ts
• packages/api/src/routes/internal/ehr/canvas/index.ts
• packages/api/src/command/internal-server/report-usage.ts
• packages/core/src/external/internal-server/client.ts
• packages/api/src/command/medical/document/document-webhook.ts
• packages/api/src/routes/middlewares/usage.ts
• packages/api/src/command/webhook/devices.ts

📄 CodeRabbit Inference Engine (.cursorrules)

Use types whenever possible

Files:

• packages/infra/lib/api-stack/api-service.ts
• packages/api/src/command/medical/document/__tests__/process-doc-query-webhook.test.ts
• packages/core/src/util/config.ts
• packages/infra/config/env-config.ts
• packages/api/src/shared/config.ts
• packages/api/src/routes/internal/ehr/canvas/setup.ts
• packages/api/src/command/internal-server/update-customer.ts
• packages/api/src/routes/internal/ehr/canvas/index.ts
• packages/api/src/command/internal-server/report-usage.ts
• packages/core/src/external/internal-server/client.ts
• packages/api/src/command/medical/document/document-webhook.ts
• packages/api/src/routes/middlewares/usage.ts
• packages/api/src/command/webhook/devices.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/infra/lib/api-stack/api-service.ts
• packages/api/src/command/medical/document/__tests__/process-doc-query-webhook.test.ts
• packages/core/src/util/config.ts
• packages/infra/config/env-config.ts
• packages/api/src/shared/config.ts
• packages/api/src/routes/internal/ehr/canvas/setup.ts
• packages/api/src/command/internal-server/update-customer.ts
• packages/api/src/routes/internal/ehr/canvas/index.ts
• packages/api/src/command/internal-server/report-usage.ts
• packages/core/src/external/internal-server/client.ts
• packages/api/src/command/medical/document/document-webhook.ts
• packages/api/src/routes/middlewares/usage.ts
• packages/api/src/command/webhook/devices.ts

Learnt from: thomasyopes
PR: metriport/metriport#3970
File: packages/api/src/external/ehr/athenahealth/command/write-back/medication.ts:17-17
Timestamp: 2025-06-06T16:45:31.832Z
Learning: The writeMedicationToChart function in packages/api/src/external/ehr/athenahealth/command/write-back/medication.ts returns a response that is not currently used by any consumers, so changes to its return type are not breaking changes in practice.

Applied to files:

• packages/api/src/command/medical/document/__tests__/process-doc-query-webhook.test.ts
• packages/api/src/command/medical/document/document-webhook.ts

Learnt from: leite08
PR: metriport/metriport#3814
File: packages/api/src/routes/internal/medical/patient-consolidated.ts:141-174
Timestamp: 2025-05-20T21:26:26.804Z
Learning: The functionality introduced in packages/api/src/routes/internal/medical/patient-consolidated.ts is planned to be refactored in downstream PR #3857, including improvements to error handling and validation.

Applied to files:

• packages/api/src/command/medical/document/__tests__/process-doc-query-webhook.test.ts
• packages/api/src/routes/internal/ehr/canvas/setup.ts
• packages/api/src/routes/internal/ehr/canvas/index.ts
• packages/api/src/command/medical/document/document-webhook.ts

Learnt from: thomasyopes
PR: metriport/metriport#3997
File: packages/api/src/routes/internal/medical/patient-job.ts:28-29
Timestamp: 2025-06-13T20:24:16.668Z
Learning: In packages/api/src/routes/internal/medical/patient-job.ts, mounting patientJobsRouter at the root path before other route handlers is intentional behavior, even though it could potentially consume requests before later handlers.

Applied to files:

• packages/api/src/routes/internal/ehr/canvas/index.ts

Learnt from: thomasyopes
PR: metriport/metriport#3383
File: packages/api/src/routes/ehr-internal/canvas/internal/patient.ts:10-24
Timestamp: 2025-03-05T21:42:32.929Z
Learning: The processPatientsFromAppointments endpoint in the Canvas API is intentionally designed to be asynchronous (fire-and-forget pattern). The endpoint returns a 200 OK response immediately after initiating the process, without waiting for it to complete. Error handling is handled through the .catch() method with processAsyncError rather than awaiting the promise.

Applied to files:

• packages/api/src/command/medical/document/document-webhook.ts

packages/shared/src/common/env-var.ts (1)

• getEnvVarOrFail (14-20)

packages/shared/src/common/env-var.ts (2)

• getEnvVarOrFail (14-20)
• getEnvVar (10-12)

packages/api/src/command/internal-server/update-customer.ts (1)

• updateCustomerBillingToPointToParent (9-19)

packages/api/src/shared/config.ts (1)

• Config (4-322)

packages/core/src/util/config.ts (1)

• Config (10-403)

packages/core/src/external/internal-server/client.ts (1)

• InternalServerApi (7-32)

packages/api/src/shared/config.ts (1)

• Config (4-322)

packages/core/src/external/internal-server/client.ts (1)

• InternalServerApi (7-32)

packages/lambdas/src/shared/capture.ts (1)

• capture (19-118)

packages/api/src/command/internal-server/report-usage.ts (1)

• reportUsage (14-26)

📄 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/command/internal-server/report-usage.ts

📄 CodeRabbit inference engine (.cursorrules)

Use types whenever possible

Files:

• packages/api/src/command/internal-server/report-usage.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/command/internal-server/report-usage.ts

packages/api/src/routes/middlewares/usage.ts (1)

• reportUsage (15-31)

packages/api/src/shared/config.ts (1)

• Config (4-318)

packages/core/src/util/config.ts (1)

• Config (10-403)

packages/core/src/external/internal-server/client.ts (1)

• InternalServerApi (8-37)

packages/lambdas/src/shared/capture.ts (1)

• capture (19-118)

📄 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/routes/internal/ehr/canvas/setup.ts

📄 CodeRabbit inference engine (.cursorrules)

Use types whenever possible

Files:

• packages/api/src/routes/internal/ehr/canvas/setup.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/routes/internal/ehr/canvas/setup.ts

packages/api/src/command/internal-server/update-customer.ts (1)

• updateCustomerBillingToPointToParent (10-21)

packages/api/src/command/mapping/cx.ts (1)

• findOrCreateCxMapping (27-43)

📄 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/routes/internal/ehr/canvas/setup.ts
• packages/api/src/routes/middlewares/usage.ts
• packages/api/src/command/webhook/devices.ts

📄 CodeRabbit inference engine (.cursorrules)

Use types whenever possible

**/*.{ts,tsx}: Prefer functional programming style functions: small, deterministic, single input and output
Avoid modifying objects received as parameters
Naming: classes and enums use PascalCase
Naming: constants, variables, and functions use camelCase
File names use kebab-case
Avoid negative names (e.g., prefer isDisabled to notEnabled)
Include units in numeric variable names when the type doesn’t convey the unit
TypeScript: use explicit types
TypeScript: prefer const over let
TypeScript: avoid any and casting from any to other types
TypeScript: use type predicates only for narrowing, not for full type coercion
TypeScript: prefer destructuring function parameters instead of multiple same-typed parameters
TypeScript: don’t use null inside the app; only at external boundaries and convert to undefined internally
TypeScript: use async/await instead of .then()
TypeScript: use strict equality ===; do not use ==
When calling a Promise-returning function without awaiting, chain .catch() to handle errors
Date/Time: always use buildDayjs() to create dayjs instances
Date/Time: prefer dayjs.duration(...) and keep values as duration
Prefer nullish coalescing (??) over OR (||) for default values
Avoid creating arrow functions
Use truthy property checks instead of the in operator (e.g., if (data.link))
Error handling: pass the original error as cause when wrapping errors
Error handling: use static error messages; put dynamic data in MetriportError.additionalInfo; error object last parameter
Global constants: move literals to constants after imports (avoid magic numbers)
Avoid multi-line logs: do not pass objects as the second parameter to console.log() or out().log()
Avoid multi-line logs: do not create multi-line strings with JSON.stringify()
Max column length is 100 characters
Use multi-line comments with /** */

Files:

• packages/api/src/routes/internal/ehr/canvas/setup.ts
• packages/api/src/routes/middlewares/usage.ts
• packages/api/src/command/webhook/devices.ts

Learnt from: CR
PR: metriport/metriport#0
File: CONVENTIONS.md:0-0
Timestamp: 2025-09-01T19:51:11.032Z
Learning: Applies to **/*.{ts,tsx} : Date/Time: prefer dayjs.duration(...) and keep values as duration

Applied to files:

• packages/api/src/routes/internal/ehr/canvas/setup.ts

Learnt from: keshavsaharia
PR: metriport/metriport#3885
File: packages/core/src/external/surescripts/client.ts:0-0
Timestamp: 2025-05-30T01:09:55.013Z
Learning: In packages/core/src/external/surescripts/client.ts, the Surescripts date formatting should use local time according to their documentation ("message-date-must-be-local"), which means buildDayjs() cannot be used since it defaults to UTC. The specific use case for transmission date formatting requires dayjs to be used directly to preserve local time behavior.

Applied to files:

• packages/api/src/routes/internal/ehr/canvas/setup.ts

Learnt from: CR
PR: metriport/metriport#0
File: CONVENTIONS.md:0-0
Timestamp: 2025-09-01T19:51:11.032Z
Learning: Applies to **/*.{ts,tsx} : Date/Time: always use buildDayjs() to create dayjs instances

Applied to files:

• packages/api/src/routes/internal/ehr/canvas/setup.ts

Learnt from: lucasdellabella
PR: metriport/metriport#3440
File: .sentryclirc:0-0
Timestamp: 2025-03-10T22:17:43.667Z
Learning: Sentry tokens and other sensitive credentials should not be stored in the repository, even if they are depermissioned or inactive. Best practice is to use environment variables or a secrets management solution.

Applied to files:

• packages/api/src/routes/internal/ehr/canvas/setup.ts

packages/api/src/command/mapping/cx.ts (1)

• findOrCreateCxMapping (27-43)

📄 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/command/internal-server/report-usage.ts
• packages/core/src/external/internal-server/client.ts

📄 CodeRabbit inference engine (.cursorrules)

Use types whenever possible

**/*.{ts,tsx}: Prefer functional programming style functions: small, deterministic, single input and output
Avoid modifying objects received as parameters
Naming: classes and enums use PascalCase
Naming: constants, variables, and functions use camelCase
File names use kebab-case
Avoid negative names (e.g., prefer isDisabled to notEnabled)
Include units in numeric variable names when the type doesn’t convey the unit
TypeScript: use explicit types
TypeScript: prefer const over let
TypeScript: avoid any and casting from any to other types
TypeScript: use type predicates only for narrowing, not for full type coercion
TypeScript: prefer destructuring function parameters instead of multiple same-typed parameters
TypeScript: don’t use null inside the app; only at external boundaries and convert to undefined internally
TypeScript: use async/await instead of .then()
TypeScript: use strict equality ===; do not use ==
When calling a Promise-returning function without awaiting, chain .catch() to handle errors
Date/Time: always use buildDayjs() to create dayjs instances
Date/Time: prefer dayjs.duration(...) and keep values as duration
Prefer nullish coalescing (??) over OR (||) for default values
Avoid creating arrow functions
Use truthy property checks instead of the in operator (e.g., if (data.link))
Error handling: pass the original error as cause when wrapping errors
Error handling: use static error messages; put dynamic data in MetriportError.additionalInfo; error object last parameter
Global constants: move literals to constants after imports (avoid magic numbers)
Avoid multi-line logs: do not pass objects as the second parameter to console.log() or out().log()
Avoid multi-line logs: do not create multi-line strings with JSON.stringify()
Max column length is 100 characters
Use multi-line comments with /** */

Files:

• packages/api/src/command/internal-server/report-usage.ts
• packages/core/src/external/internal-server/client.ts

Learnt from: thomasyopes
PR: metriport/metriport#3466
File: packages/api/src/routes/ehr/shared.ts:122-147
Timestamp: 2025-03-17T17:01:17.227Z
Learning: Avoid using console.log and console.error in packages other than utils, infra and shared, and try to use out().log instead according to Metriport's coding guidelines.

Applied to files:

• packages/api/src/command/internal-server/report-usage.ts

Learnt from: thomasyopes
PR: metriport/metriport#3466
File: packages/api/src/routes/internal/internal.ts:0-0
Timestamp: 2025-03-17T23:45:45.512Z
Learning: The internal.ts file in packages/api/src/routes/internal/ is excluded from PR changes related to replacing console.log with out().log.

Applied to files:

• packages/api/src/command/internal-server/report-usage.ts

Learnt from: alexeysergeev-cm
PR: metriport/metriport#4367
File: packages/api/src/routes/internal/ehr/canvas/index.ts:3-8
Timestamp: 2025-08-14T20:17:36.570Z
Learning: In the Metriport API codebase, internal routes (mounted under /internal) rely on API Gateway for access control rather than having code-level internal auth middleware. This architectural pattern is intentional and expected.

Applied to files:

• packages/core/src/external/internal-server/client.ts

packages/api/src/shared/config.ts (1)

• Config (4-322)

packages/core/src/external/internal-server/client.ts (1)

• InternalServerApi (10-46)

packages/lambdas/src/shared/capture.ts (1)

• capture (19-118)

packages/core/src/util/config.ts (2)

• isSandbox (25-27)
• Config (11-408)

packages/shared/src/index.ts (1)

• MetriportError (44-44)

📄 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/core/src/external/internal-server/client.ts

📄 CodeRabbit inference engine (.cursorrules)

Use types whenever possible

**/*.{ts,tsx}: Prefer functional programming style functions: small, deterministic, single input and output
Avoid modifying objects received as parameters
Naming: classes and enums use PascalCase
Naming: constants, variables, and functions use camelCase
File names use kebab-case
Avoid negative names (e.g., prefer isDisabled to notEnabled)
Include units in numeric variable names when the type doesn’t convey the unit
TypeScript: use explicit types
TypeScript: prefer const over let
TypeScript: avoid any and casting from any to other types
TypeScript: use type predicates only for narrowing, not for full type coercion
TypeScript: prefer destructuring function parameters instead of multiple same-typed parameters
TypeScript: don’t use null inside the app; only at external boundaries and convert to undefined internally
TypeScript: use async/await instead of .then()
TypeScript: use strict equality ===; do not use ==
When calling a Promise-returning function without awaiting, chain .catch() to handle errors
Date/Time: always use buildDayjs() to create dayjs instances
Date/Time: prefer dayjs.duration(...) and keep values as duration
Prefer nullish coalescing (??) over OR (||) for default values
Avoid creating arrow functions
Use truthy property checks instead of the in operator (e.g., if (data.link))
Error handling: pass the original error as cause when wrapping errors
Error handling: use static error messages; put dynamic data in MetriportError.additionalInfo; error object last parameter
Global constants: move literals to constants after imports (avoid magic numbers)
Avoid multi-line logs: do not pass objects as the second parameter to console.log() or out().log()
Avoid multi-line logs: do not create multi-line strings with JSON.stringify()
Max column length is 100 characters
Use multi-line comments with /** */

Files:

• packages/core/src/external/internal-server/client.ts

packages/core/src/util/config.ts (1)

• Config (11-408)

packages/shared/src/index.ts (1)

• MetriportError (44-44)