sindresorhus/is · error · TypeError

Expected value which is `T`, received value of type `${is(in

Error message

Expected value which is `T`, received value of type `${is(instance)}`.

What it means

Thrown by `assertDirectInstanceOf(instance, class_)` when `isDirectInstanceOf` fails — the value's prototype must be exactly `class_.prototype` (`Object.getPrototypeOf(instance) === class_.prototype`), not an instance of a subclass or from another realm. The message's literal `T` is the generic parameter name, so the expected-type text is unfortunately non-descriptive; pass a custom `message` for clarity.

Source

Thrown at source/index.ts:1550

		throw new TypeError(message ?? typeErrorMessage('Class', value));
	}
}

export function assertDataView(value: unknown, message?: string): asserts value is DataView {
	if (!isDataView(value)) {
		throw new TypeError(message ?? typeErrorMessage('DataView', value));
	}
}

export function assertDate(value: unknown, message?: string): asserts value is Date {
	if (!isDate(value)) {
		throw new TypeError(message ?? typeErrorMessage('Date', value));
	}
}

export function assertDirectInstanceOf<T>(instance: unknown, class_: Class<T>, message?: string): asserts instance is T {
	if (!isDirectInstanceOf(instance, class_)) {
		throw new TypeError(message ?? typeErrorMessage('T', instance));
	}
}

export function assertEmptyArray(value: unknown, message?: string): asserts value is never[] {
	if (!isEmptyArray(value)) {
		throw new TypeError(message ?? typeErrorMessage('empty array', value));
	}
}

export function assertEmptyMap(value: unknown, message?: string): asserts value is Map<never, never> {
	if (!isEmptyMap(value)) {
		throw new TypeError(message ?? typeErrorMessage('empty map', value));
	}
}

export function assertEmptyObject<Key extends keyof any = string>(value: unknown, message?: string): asserts value is Record<Key, never> {
	if (!isEmptyObject(value)) {
		throw new TypeError(message ?? typeErrorMessage('empty object', value));

View on GitHub ↗ (pinned to 7821031c66)

Solutions

If subclass instances should be accepted, use a plain `instanceof` check or `assert.instanceOf`-style logic instead of the direct check.
Deduplicate the package providing the class (`npm dedupe`, check `npm ls <pkg>`) so both sides share one class identity.
Pass a custom message so failures name the real class: `assertDirectInstanceOf(x, Foo, 'Expected direct Foo instance')`.
Ensure the value isn't crossing a realm boundary; reconstruct it locally if it is.

Example fix

// before — subclass rejected by direct check
assert.directInstanceOf(new AdminUser(), User);
// after — accept subclasses
if (!(user instanceof User)) throw new TypeError('Expected User');

Defensive patterns

Strategy: type-guard

Validate before calling

if (!(instance instanceof ExpectedClass)) {
  // wrong class or cross-module duplicate — construct via the same module's export
}

Type guard

function isInstanceOf<T>(instance: unknown, ctor: new (...args: any[]) => T): instance is T {
  return instance instanceof ctor;
}

Try / catch

try {
  assert.directInstanceOf(instance, ExpectedClass);
} catch (error) {
  if (error instanceof TypeError) {
    // note: directInstanceOf requires the EXACT class — subclasses fail; duplicate package versions also break identity
  } else throw error;
}

Prevention

directInstanceOf checks the immediate prototype — a subclass instance fails; use plain instanceof checks if subclasses should pass
Duplicate copies of a package in node_modules create distinct class identities — dedupe so both sides import the same module
instanceof fails across realms (workers, vm, iframes) — pass plain data across boundaries and reconstruct locally

When it happens

Trigger: Passing a subclass instance (direct check rejects inheritance, unlike `instanceof`); passing an object created with `Object.create` of a different prototype; instances crossing realm boundaries (iframe, vm module, worker) where the class identity differs; duplicate copies of a library creating two distinct class objects.

Common situations: npm dependency duplication (two versions of a package means two `Error`/model class identities); Jest/vitest module isolation creating fresh class copies per test file; extending a class and expecting the parent's direct check to accept it; Node `vm` or JSDOM realms.

Related errors

AI-assisted analysis of sindresorhus/is@7821031c66 (2026-07-31). Data as JSON: /data/errors/ed236a1ffbbbf70e.json. Report an issue: GitHub ↗.