TypeScript Error Codes List: Meaning, Common Causes, and Fixes

Overview

This article is a working reference for high-frequency TypeScript compiler errors. It is not a complete catalog of every diagnostic the compiler can emit. Instead, it focuses on the error codes that show up often across frontend apps, Node services, shared libraries, test suites, and JavaScript to TypeScript migration work.

Two things make TypeScript errors hard to debug:

• The message often points to the place the type conflict appears, not the original source of the bad type.
• Many errors are downstream effects of configuration choices in tsconfig.json, framework tooling, or incomplete type narrowing.

A reliable way to read TypeScript compiler errors is to separate them into a few categories:

• Assignment errors: a value cannot be assigned to a variable, return type, or property.
• Argument errors: a value passed into a function does not match the parameter type.
• Property access errors: TypeScript cannot prove that a property or method exists.
• Nullability errors: a value may be null or undefined.
• Module and config errors: imports, exports, target settings, or library definitions do not line up.

Once you know which category you are in, most fixes become narrower and safer. The goal is rarely to “make the error disappear.” The goal is to express the program logic clearly enough that the compiler can verify it.

Core concepts

This section covers common TypeScript error codes, their meaning, common causes, and fixes that hold up well over time.

TS2322: Type 'X' is not assignable to type 'Y'

Meaning: You are assigning a value to something with a different expected type.

Common causes:

• A property is optional in one place and required in another.
• A function returns a wider or narrower shape than declared.
• string | undefined is being assigned to string.
• An inferred array element type does not match the target array type.

type User = { id: string; name: string };

const user: User = {
  id: '1'
  // name missing
};

Fixes:

• Add the missing field if the value really should satisfy the target type.
• Change the target type if the contract is too strict.
• Narrow before assignment.
• Avoid papering over the problem with as unless you are bridging a known boundary.

const maybeName: string | undefined = getName();

if (maybeName !== undefined) {
  const name: string = maybeName;
}

In practice, TS2322 is often the most useful error in a codebase. It catches mismatches early and usually points to an unclear contract.

TS2345: Argument of type 'X' is not assignable to parameter of type 'Y'

Meaning: A function call is receiving a value that does not match the declared parameter type.

Common causes:

• Passing a union where the function expects a single concrete type.
• Passing partial API data into a function that expects validated data.
• Using event values, query params, or environment variables as if they were already parsed.

function sendEmail(address: string) {}

const input: string | undefined = process.env.ADMIN_EMAIL;
sendEmail(input); // TS2345

Fixes:

• Validate or narrow the value before the call.
• Overload or widen the function signature only if the function truly supports those cases.
• Create a parsing layer at the edges of the system.

if (!input) {
  throw new Error('ADMIN_EMAIL is required');
}

sendEmail(input);

If you see TS2345 often, your application boundaries may be under-typed. A small validation step near external inputs usually removes many downstream errors.

TS2339: Property 'X' does not exist on type 'Y'

Meaning: TypeScript does not believe the property exists on the current type.

Common causes:

• Accessing a property on a union without narrowing.
• Using plain object, {}, or overly broad generic constraints.
• Incorrect assumptions about API responses or framework-specific objects.

type Result = { ok: true; data: string } | { ok: false; error: Error };

function handle(result: Result) {
  return result.data; // TS2339
}

Fixes:

• Use discriminated unions and narrow based on a tag field.
• Model the object shape explicitly.
• Prefer unknown plus runtime checks over vague object types.

function handle(result: Result) {
  if (result.ok) {
    return result.data;
  }
  return result.error.message;
}

TS2339 is usually a signal that your program knows more than your types currently express.

TS2532: Object is possibly 'undefined'

Meaning: With strict null checks enabled, TypeScript sees a path where the value may be undefined.

Common causes:

• Optional properties.
• Array lookups or map access.
• Framework hooks or async-loaded data used before existence checks.

type Config = {
  api?: {
    baseUrl: string;
  };
};

function getBaseUrl(config: Config) {
  return config.api.baseUrl; // TS2532
}

Fixes:

• Guard explicitly.
• Use optional chaining when an undefined result is acceptable.
• Restructure data flow so required values are validated earlier.

function getBaseUrl(config: Config) {
  if (!config.api) {
    throw new Error('Missing api config');
  }
  return config.api.baseUrl;
}

Use the non-null assertion operator ! sparingly. It is useful when you know more than the compiler in a very local case, but overuse weakens the value of TypeScript debugging.

TS7006: Parameter implicitly has an 'any' type

Meaning: A function parameter lacks a type annotation and cannot be inferred safely under your current compiler settings.

Common causes:

• Migration from JavaScript with noImplicitAny enabled.
• Callbacks written without contextually typed parameters.
• Utility functions that were never formally typed.

function formatUser(user) {
  return user.name.toUpperCase();
}

Fixes:

• Add the parameter type directly.
• Extract and reuse named types for frequently shared shapes.
• Use generics when the function is meant to be reusable across inputs.

type User = { name: string };

function formatUser(user: User) {
  return user.name.toUpperCase();
}

TS7006 is common in migration work. The right response is usually not to disable the rule, but to type the function boundary and let inference handle the internals.

TS2307: Cannot find module 'X' or its corresponding type declarations

Meaning: TypeScript cannot resolve an import or its type information.

Common causes:

• Wrong import path.
• Missing package or missing type declarations.
• Path alias configuration in tsconfig.json does not match the build tool.
• ESM and CommonJS settings are mixed inconsistently.

Fixes:

• Verify the path and file extension expectations in your toolchain.
• Install the required package and any type definitions if needed.
• Keep bundler, test runner, and TypeScript path mapping aligned.
• Review baseUrl, paths, module, and moduleResolution.

This error often looks like a package problem but is really a project configuration problem. When a project uses React, Next.js, Node, Vitest, or Jest together, mismatched module settings can create confusing import failures.

TS2454: Variable is used before being assigned

Meaning: A variable might be read before it gets a value.

Common causes:

• Conditional initialization.
• Values assigned inside branches the compiler cannot guarantee will run.
• Mutable local variables used instead of direct expressions.

let token: string;

if (Math.random() > 0.5) {
  token = 'abc';
}

console.log(token); // TS2454

Fixes:

• Initialize immediately where possible.
• Use string | undefined if absence is real, then narrow.
• Refactor branch-heavy code into expressions or early returns.

TS2454 often improves code clarity because it pushes you toward explicit initialization.

TS2741 and related missing property errors

Meaning: An object is missing a required property from the expected type.

Common causes:

• Partial form state treated as a fully valid domain object.
• Incomplete test fixtures.
• Confusing transport models with internal models.

Fixes:

• Split partial and complete states into separate types.
• Use builders or factory helpers in tests.
• Model validation stages instead of forcing one type to do everything.

This class of error is particularly useful in React TypeScript tutorial scenarios, form handling, and API response shaping.

TS2367: This comparison appears to be unintentional

Meaning: TypeScript believes two compared values have no overlap.

Common causes:

• Comparing incompatible literal unions.
• Incorrect boolean logic.
• Narrowing in one branch that makes a later comparison impossible.

Fixes:

• Check whether you meant || instead of &&.
• Review enum or union member values.
• Look for stale conditions after refactoring.

This error is often a genuine bug detector, not just a typing complaint.

How to fix errors without weakening the type system

When developers are under pressure, the tempting fixes are predictable: any, broad assertions, non-null assertions everywhere, or relaxed compiler settings. Those tools have a place, but they should be the last step, not the first.

A safer order of operations is:

1. Read the full error and identify the expected type versus the actual type.
2. Find where the actual type was introduced or widened.
3. Narrow with a guard, parser, or discriminated union.
4. Adjust the function signature only if the implementation genuinely supports more cases.
5. Use assertions only at trusted boundaries you cannot model more precisely.

If your team is building internal tooling around TypeScript diagnostics and editor workflows, the decision process for automation and assistance may overlap with broader developer tooling choices. For that angle, see Which LLM for TypeScript dev tooling? A practical decision matrix for teams.

Related terms

This section gives the vocabulary that often appears around TypeScript error fixes.

Type narrowing

Type narrowing is the process of proving to TypeScript that a value is more specific than its original type. Common narrowing tools include typeof, in, equality checks, truthiness checks, and custom type predicates. Many ts2322 fix and ts2345 fix cases are really narrowing problems.

Discriminated unions

A discriminated union is a union with a shared tag field such as kind or status. They make TS2339 and TS2345 much easier to resolve because each branch becomes explicit and safe.

Strict null checks

This compiler behavior treats null and undefined as distinct values that must be handled. Many useful TypeScript error fixes depend on this being enabled, because it forces edge cases into the open.

Structural typing

TypeScript checks compatibility based on shape rather than nominal class identity. This is powerful, but it also means object literals can trigger missing property errors earlier than expected. That is usually a benefit, not a nuisance.

Type assertions

An assertion such as value as SomeType tells the compiler to trust you. Assertions are sometimes necessary at boundaries, but they do not perform runtime validation. If the data is uncertain, parse it first.

Compiler options

Your typescript tsconfig choices influence which errors appear and how early they surface. Settings such as strict, noImplicitAny, exactOptionalPropertyTypes, moduleResolution, and lib can change both the frequency and the shape of diagnostics.

Practical use cases

Here is how to apply this TypeScript errors list in day-to-day work.

1. Debug a failing build quickly

Start by grouping the error:

• TS2322 or TS2345: inspect the source type, not just the failing line.
• TS2339: check whether a union needs narrowing.
• TS2532: validate or guard nullable values earlier.
• TS2307: compare TypeScript module resolution with your actual runtime and bundler config.

This reduces time spent chasing the wrong layer of the problem.

2. Improve JavaScript to TypeScript migration

In migration work, errors often cluster around implicit any, nullable values, and incomplete object shapes. Do not try to make the whole application perfectly typed in one pass. Instead:

1. Type function boundaries first.
2. Enable stricter settings gradually.
3. Convert shared domain models before UI details.
4. Use runtime validation at external boundaries.

If your team is formalizing how people learn these patterns, Design an in-house TypeScript learning path that actually moves the needle is a useful companion read.

3. Reduce recurring React and frontend errors

Frontend projects commonly hit these patterns:

• Props that are optional in one component and required in another.
• State initialized as null then used as if loaded.
• Event targets treated as specific element types without guards.
• API data rendered before validation.

Good fixes include explicit loading states, narrower prop contracts, and parsing API responses into stable internal types before rendering.

4. Keep Node and backend types honest

In Node services, TS2345 and TS2532 often come from environment variables, request inputs, database records, or JSON payloads. Treat these as untrusted until parsed. A small validation layer prevents broad type assertions from spreading across the service.

Teams working on service boundaries and system isolation may also find value in Limit blast radius: architecting TypeScript microservices with the same discipline as quantum noise research.

5. Use tests to lock in fixes

A good TypeScript error fix often belongs with one of these test strategies:

• Runtime tests for parsing and validation logic.
• Type tests for utility types and generic helpers.
• Fixture builders that create complete domain objects cleanly.

This matters especially when fixing errors by redesigning data contracts instead of suppressing diagnostics.

6. Build a reusable team playbook

For teams, recurring compiler errors are rarely just individual mistakes. They usually indicate common failure points in project setup, model design, or review habits. A lightweight team playbook can include:

• Top ten error codes seen in your codebase.
• Preferred fixes and anti-patterns.
• Approved places for assertions.
• Recommended tsconfig defaults.
• Examples from your actual React, Node, or shared package code.

If you are enforcing standards with AST-driven checks and custom review automation, Write Kodus rules that understand TypeScript: plain-language to AST-driven checks connects well with this workflow.

When to revisit

Revisit this reference when your compiler behavior, framework setup, or code modeling habits change. The same error code can show up for slightly different reasons after a tooling upgrade or architecture shift.

In practice, update your understanding of common TypeScript compiler errors when:

• You enable stricter compiler options such as strict or exactOptionalPropertyTypes.
• You move between CommonJS and ESM module systems.
• You introduce a new framework, test runner, or bundler.
• You begin a JavaScript to TypeScript migration.
• You notice the same error code appearing repeatedly in pull requests.
• You refactor API models, shared utility types, or validation boundaries.

A practical next step is to create your own internal error index. Start with TS2322, TS2345, TS2339, TS2532, TS7006, and TS2307. For each code, record one real example from your project, the root cause, and the preferred fix. That turns TypeScript debugging from one-off searching into a durable team asset.

If you only adopt one habit from this guide, make it this: fix the type at the boundary where uncertainty enters the system. Most TypeScript errors become smaller, clearer, and less repetitive once inputs are validated and contracts are explicit.