Fix TypeScript “Property Does Not Exist on Type” Errors

TypeScript reports a missing-property error when the type of a value does not declare the property you are trying to read. This page explains how to model dynamic JavaScript values safely, when to use any or index signatures, and why making the compiler emit JavaScript is different from making a build succeed.

TypeScript checks your code before it runs. When you write value.x, TypeScript looks at the declared or inferred type of value and asks: does this type promise that an x property exists?

interface User {
  name: string;
}

const user: User = { name: "Ada" };
console.log(user.x); // Error: Property 'x' does not exist on type 'User'.

At runtime, JavaScript can add properties freely. TypeScript cannot safely assume that a property exists just because JavaScript allows it. The error is useful because it catches:

• Misspellings such as user.nmae.
• Incorrect assumptions about API response data.
• Calling a JavaScript library without accurate type declarations.
• Accessing optional or dynamic properties without checking first.

The best solution is usually to describe the value accurately with a TypeScript type. If the value is genuinely dynamic, use a type designed for dynamic keys rather than disabling type checking for an entire project.

A TypeScript compiler error normally causes tsc to return a non-zero exit code, commonly 1. Build tools, including Visual Studio/MSBuild integrations, interpret that exit code as a failed build. Even if JavaScript is emitted, the build can still be marked as failed.

Think of a TypeScript type as an inventory list attached to a box.

If a box is labelled User, and its inventory says it contains only name, TypeScript will not let you take out x. JavaScript might still allow it at runtime—perhaps someone put x in the box later—but TypeScript wants evidence before it says that operation is safe.

You can solve this in three main ways:

• Update the inventory list: add x to the type.
• Say the box may contain arbitrary labelled items: use an index signature or Record.
• Treat the box as unknown/unverified and inspect it before using it.

Using any is like removing the inventory list entirely. It is sometimes useful at boundaries with untyped JavaScript, but it also removes many helpful safety checks.

When a property is part of the data model, declare it in the type.

interface Product {
  id: number;
  name: string;
  category: string;
}

const product: Product = {
  id: 1,
  name: "Keyboard",
  category: "Hardware"
};

console.log(product.category); // "Hardware"

When an object can have arbitrary string keys, use an index signature or Record.

const settings: Record<string, string> = {
  theme: "dark",
  language: "en"
};

console.log(settings["theme"]);

For a known fixed field plus additional dynamic fields:

interface ApiResult {
  status: string;
  [key: string]: string;
}

const result: ApiResult = {
  status: "ok",
  requestId: "abc-123"
};

console.log(result.requestId);

If you are integrating an untyped JavaScript value, narrow it before property access:

function hasProperty(value: object, key: string): value is Record<string, unknown> {
  return key in value;
}

const data: object = { x: 42 };

if (hasProperty(data, "x")) {
  console.log(data.x);
}

As a narrow escape hatch, you can assert a type when you know more than TypeScript does:

const legacyValue: unknown = { x: 42 };
const valueWithX = legacyValue as { x: number };

console.log(valueWithX.x);

The assertion changes TypeScript's view of the value; it does not validate the value at runtime.

Consider a response that contains a required name and optional metadata.

interface Customer {
  name: string;
  metadata?: Record<string, string>;
}

const customer: Customer = {
  name: "Lin",
  metadata: { tier: "gold" }
};

const tier = customer.metadata?.["tier"];
console.log(tier);

Step by step:

1. The Customer type requires name.
2. metadata? has a ?, so it may be absent.
3. If present, metadata is a dictionary whose keys and values are strings.
4. customer.metadata?.["tier"] uses optional chaining. If metadata is missing, the expression becomes undefined instead of throwing.
5. In this object, metadata exists and contains tier, so the output is gold.

By contrast, this is rejected:

console.log(customer.tier);

tier is not a direct property of Customer; it is a dynamic key inside metadata.

Common places where missing-property errors reveal an important design decision include:

• API responses: Define interfaces for expected JSON fields, and validate or narrow data received from external services.
• Application configuration: Use Record<string, string> for environment-style key/value settings.
• Plugin metadata: A plugin may provide arbitrary metadata keys, while still having required fields such as name and version.
• Legacy JavaScript libraries: Add type declarations, wrapper functions, or small type assertions at the integration boundary.
• Form data: Model known fields explicitly and keep extra submitted fields in a dictionary if the form is configurable.
• Database JSON columns: Represent stable fields with interfaces and variable fields with Record<string, unknown>.

In production code, developers typically avoid globally ignoring these errors. Instead, they isolate dynamic or untyped data at boundaries.

Validate external data once

function getDisplayName(value: unknown): string | undefined {
  if (
    typeof value === "object" &&
    value !== null &&
    "displayName" in value &&
    typeof (value as Record<string, unknown>).displayName === "string"
  ) {
    return (value as Record<string, string>).displayName;
  }

  return undefined;
}

The rest of the application can work with a known string | undefined result instead of repeatedly handling an untyped object.

Use guard clauses for optional values

function printCity(customer: { address?: { city?: string } }): void {
  const city = customer.address?.city;

  if (!city) {
    return;
  }

  console.log(city);
}

Keep any at a small boundary

function readLegacyOption(source: any): string | undefined {
  return typeof source.option === "string" ? source.option : undefined;
}

If a legacy library has no types, a small wrapper is safer than allowing any to spread through the entire codebase.

Build behavior

noEmitOnError controls whether JavaScript files are emitted when TypeScript reports errors:

{
  "compilerOptions": {
    "noEmitOnError": false
  }
}

This can allow JavaScript output, but it does not make type errors correct, and tsc can still return a failure exit code. A build system that must continue despite an intentionally failing command has to be configured separately—for example, by changing the relevant MSBuild task's error-handling behavior. That is a build-policy choice and can hide real failures, so it should be temporary and narrowly scoped.

For older Visual Studio/TypeScript projects, options and project-file integration vary by the installed TypeScript tooling version. The durable fix is still to correct the types, use appropriate declarations, or add local assertions for legacy JavaScript boundaries.

Adding a property only at runtime

interface User {
  name: string;
}

const user: User = { name: "Ada" };
(user as any).role = "admin";
console.log(user.role); // Still an error without another assertion

Avoid this by declaring the property:

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

Using any everywhere

const response: any = getResponse();
console.log(response.usre.nmae); // Typo is not detected

Use unknown for data you have not verified, then narrow it. Use any only where the loss of checking is deliberate and contained.

Using dot notation for an arbitrary key

const labels: Record<string, string> = { "first-name": "Ada" };

// labels.first-name is parsed as subtraction and is invalid for this key.
console.log(labels["first-name"]);

Use bracket notation when the key is dynamic, stored in a variable, or not a valid identifier.

Assuming a type assertion performs validation

const value = JSON.parse("{}") as { x: number };
console.log(value.x); // undefined at runtime

Assertions affect compile-time checking only. Validate external data if the property must truly exist.

Suppressing errors before understanding them

Modern TypeScript supports a line-level suppression:

// @ts-ignore
legacyValue.x();

This should be rare. Prefer // @ts-expect-error when deliberately testing that an error exists, because TypeScript reports an error if the expected error later disappears. Very old TypeScript versions may support neither directive; use a local type assertion or improve the declaration instead.

noEmitOnError and error suppression solve different problems:

• value.x is allowed only when x exists on the type of value.

• Add a stable property to an interface:

  interface Item { x: number }
  

• Make a known property optional:

  interface Item { x?: number }
  

• Use arbitrary string keys:

  const values: Record<string, number> = {};
  values["x"] = 1;
  

• Access optional nested values safely:

  const value = item.details?.x;
  

• Use unknown for unverified external data; narrow before use.

• A type assertion such as value as { x: number } does not check runtime data.

• any disables checks; keep it local to legacy boundaries.

• noEmitOnError: false permits output despite errors, but a compiler error can still cause tsc and a Visual Studio build to fail.

Why does TypeScript say a property does not exist when it exists in JavaScript?

TypeScript checks the declared type, not every possible runtime modification. Add the property to the type, model dynamic keys, or validate and narrow external data.

How do I allow dynamic object properties in TypeScript?

Use Record<string, T> when keys are arbitrary and values share type T, such as Record<string, string>.

Should I use any to fix a property-does-not-exist error?

Only as a limited escape hatch for untyped or legacy code. An interface, index signature, unknown, or a local assertion is usually safer.

Does noEmitOnError: false ignore TypeScript errors?

No. It allows JavaScript output to be generated despite errors. The errors still exist, and tsc may still return a non-zero exit code that fails a build.

Can I ignore one TypeScript error?

In modern TypeScript, // @ts-ignore suppresses the error on the next line. Use it sparingly; correcting the type or using a narrow assertion is preferable.

What is the difference between unknown and any?

any permits any operation without checking. unknown requires you to check or narrow the value before accessing properties, making it safer for external data.

Why does Visual Studio stop building when TypeScript has errors?

Visual Studio's build system treats the non-zero exit code from tsc.exe as a failed build step. This is separate from whether JavaScript files were emitted.

• TypeScript interfaces — Define the expected properties of object-shaped values.
• Type aliases — Another way to describe object and union shapes.
• Optional properties — Model fields that are known but may be absent.
• Index signatures — Allow dynamic keys on an object type.
• Record utility type — Concise syntax for key/value dictionaries.
• Type assertions — Tell TypeScript about knowledge it cannot infer.
• unknown vs any — Choose a safe type for values from untyped sources.
• Type guards — Check a value at runtime and narrow its type.
• Optional chaining — Safely access properties through potentially missing values.
• tsconfig compiler options — Configure TypeScript emission and checking behavior.
• Declaration files — Add types for JavaScript libraries and existing code.