Check Undefined in JavaScript: Value, Presence and Unknown Names

The task

Inspect two settings records and an identifier that this script never declares. Then demonstrate why typeof is not a universal escape from a let binding’s initialization rules.

Runnable Node 22 example

const assert = require('node:assert/strict');

const missing = {};
const explicit = {caption: undefined};
assert.equal(missing.caption === undefined, true);
assert.equal(explicit.caption === undefined, true);
assert.equal(Object.hasOwn(missing, 'caption'), false);
assert.equal(Object.hasOwn(explicit, 'caption'), true);
assert.equal(typeof rxNeverDeclared, 'undefined');
assert.throws(() => rxNeverDeclared, ReferenceError);
assert.throws(() => { typeof later; let later; }, ReferenceError);
console.log(`missingOwn=${Object.hasOwn(missing, 'caption')}; explicitOwn=${Object.hasOwn(explicit, 'caption')}`);

Expected output and explanation

Both property reads produce undefined, but only one record owns caption. The presence check therefore preserves information that a value comparison alone loses. This fixture asks about presence rather than supplying a default.

typeof on the never-declared identifier returns the string undefined, while directly reading it throws. The final error shows the important limit: a lexical binding in its temporal dead zone can still throw under typeof. It is not the same situation as an unresolvable name.

Pitfall to check

Do not collapse undefined, null and empty text unless the input contract says they mean the same thing. Also avoid using a property’s truthiness to infer presence, since an owned false or zero value would be missed.