Guard nullable inputs

When a value can be undefined/null, do not assume it exists—guard it before access and keep the type model consistent.

Rules

• Use optional chaining / nullish guards when reading fields from optional params:

  function f(params?: { message?: string | ((d: unknown[]) => string) }) {
    const message =
      typeof params?.message === "function"
        ? params.message
        : errorUtil.toString(params?.message);
  }
  

• Before using in, Object.keys, or nested properties, ensure the container object exists:

  if (refSeen.def && key in refSeen.def) {
    // safe
  }
  

• If a value is not actually optional, don’t add optional parameters/fallbacks—prefer required types (avoid “unnecessary undefined handling”).
• If you convert invalid data to undefined (e.g., coercion failures), make sure downstream code treats that undefined as the expected “invalid” state and update types accordingly.
• Be consistent in how you model “missing” vs “present but undefined” in types; adding : undefined can change runtime semantics ("prop" in obj). Prefer property absence when that’s the intended meaning.

Outcome: fewer runtime TypeErrors and clearer, more intentional null/undefined handling across the codebase.