TS18048: 'x' is possibly 'undefined'

The exact error string

interface User { name: string; email?: string; }

function send(user: User) {
  mailer.to(user.email);
  //         ~~~~~~~~~~
  // error TS18048: 'user.email' is possibly 'undefined'.
}

The property email is optional (email?: string), so its type is string | undefined. mailer.to wants a defined string, and TypeScript can see a path where user.email is undefined — so it stops you. This is the same check as the expression-form TS2532 "Object is possibly 'undefined'"; TS18048 just names the specific identifier. Its null-side siblings are TS18047: 'x' is possibly 'null' and TS2531: Object is possibly 'null', fixed exactly the same way.

Where does the undefined come from? (triage)

The fix depends on the source. The common ones:

• Optional property or parameter — email?: string, function f(x?: number). Type is T | undefined.
• .find() / .at() — return T | undefined because nothing may match.
• Map.get() — returns V | undefined; the key may be absent.
• Array/record index under noUncheckedIndexedAccess — arr[i] becomes T | undefined.
• Environment variables — process.env.FOO is typed string | undefined.
• A function that may return undefined, or a value narrowed to undefined on one branch.

Fix 1: narrow with a guard

An if that rules out undefined narrows the value for the rest of the block — TypeScript's control-flow analysis removes undefined from the type inside the guard:

function send(user: User) {
  if (user.email) {
    mailer.to(user.email);   // ✅ string here — undefined ruled out
  }
}

// early-return (guard clause) keeps the happy path flat
function send2(user: User) {
  if (user.email === undefined) return;
  mailer.to(user.email);     // ✅ string from here on
}

Use === undefined (or != null to catch both null and undefined) when the value could legitimately be a falsy-but-valid value like 0 or "" — a bare if (x) would wrongly skip those.

Fix 2: default with ??, read with ?.

When you'd rather substitute a value than branch, nullish coalescing supplies a fallback only for null/undefined (not for 0 or "", unlike ||):

const email = user.email ?? "no-reply@example.com";  // always a string
const port  = Number(process.env.PORT ?? "3000");    // env var defaulted

// optional chaining reads a nested possibly-undefined value safely
const city = user.address?.city ?? "Unknown";

Optional chaining (?.) short-circuits to undefined the moment any link is nullish, so it's the natural partner of ??: chain to read, coalesce to default.

Fix 3: give it a default at the source

Often the cleanest fix is to remove the undefined before the value ever spreads through your code — a default parameter, a destructuring default, or a required type where the value is genuinely always present:

// default parameter
function greet(name: string = "friend") {
  return `Hi, ${name}`;      // name is never undefined inside
}

// destructuring default
function paginate({ page = 1, size = 20 }: { page?: number; size?: number }) {
  return { page, size };     // both are numbers, not number | undefined
}

If the property is never actually optional in practice, the real fix is the type: change email?: string to email: string so the whole class of error disappears at the definition instead of at every use site.

Fix 4: handle the not-found case for find / get / index

find, Map.get, and indexed access under noUncheckedIndexedAccess are possibly undefined by design — the lookup can miss. Handle the miss explicitly rather than pretending it can't happen:

const admin = users.find(u => u.role === "admin");  // User | undefined
if (!admin) throw new Error("no admin configured");
console.log(admin.name);       // ✅ User here

const score = scores.get(userId);                   // number | undefined
console.log((score ?? 0).toFixed(1));               // default the miss

// with noUncheckedIndexedAccess on:
const first = rows[0];                              // Row | undefined
if (first) process(first);

Fix 5: the non-null assertion (!) — only when you can prove it

The postfix ! operator removes null and undefined from a value's type. It performs no runtime check — it's a promise you make to the compiler. Use it only where you can guarantee the value is defined but the compiler can't follow the reasoning:

// a required env var validated at startup, so it's guaranteed later
const dbUrl = process.env.DATABASE_URL!;   // asserts defined — no check happens

// ⚠️ if DATABASE_URL is actually unset, this becomes a runtime crash later,
// not a TS error. Prefer validating and throwing a clear message instead:
// const dbUrl = process.env.DATABASE_URL ?? fail("DATABASE_URL is required");

If your guess is wrong, x! converts a compile-time warning into exactly the runtime failure it was protecting you from — a "Cannot read properties of undefined" crash. That's why a real guard or a validated default is almost always better; keep ! for the rare case you can genuinely prove and comment why.

What NOT to do

• Don't scatter ! to silence every occurrence. Each one is an unchecked assumption; a wrong one is a production crash with no compile-time warning.
• Don't disable strictNullChecks. It's the flag that finds these bugs. Turning it off doesn't make the value defined — it just hides every place it might not be, including the ones that are real.
• Don't reach for as any. That's the unknown/any escape hatch and it throws away all checking on the value, not just the undefined part.

Debugging checklist

• ✓ Identify the source — optional prop, find/get, indexed access, env var, or a maybe-undefined return
• ✓ Want to branch? Guard with if (x !== undefined) (or != null for both null & undefined)
• ✓ Want a fallback? x ?? default; read nested with x?.prop
• ✓ Value always present in reality? Make the type required — drop the ?
• ✓ find/Map.get/index? Handle the not-found case explicitly
• ✓ Reaching for x!? Only if you can prove it — otherwise it just moves the crash to runtime
• ✓ Same as TS2532 (object) / TS18047,TS2531 (null)? Same cause, same fixes