How to Ignore TypeScript Errors: @ts-ignore, File-Level Alternatives, and Safer Patterns

By the end of this page, you will understand how @ts-ignore works in TypeScript, why it only applies to the next line, and what to use instead when you want to suppress errors across multiple lines or a whole file. You will also learn safer alternatives that are easier to maintain in real codebases.

TypeScript provides special comments called compiler directives that affect type checking.

One of the most common is:

// @ts-ignore

This directive suppresses TypeScript errors on only the next line. It does not support a multi-line block form like some languages do with block comments.

Important idea

There is no built-in @ts-ignore for a block of code.

If you need to suppress several lines, your options are usually:

• put // @ts-ignore above each line that needs suppression
• use // @ts-expect-error for each expected error line
• move the code into a separate file and use // @ts-nocheck at the top of that file
• rewrite the code so TypeScript can understand the types correctly
• use type assertions or better type definitions instead of ignoring errors

Why TypeScript works this way

TypeScript is designed to catch mistakes as close as possible to where they happen. A block-level ignore would make it easy to hide unrelated problems inside a larger region of code.

Limiting suppression to one line helps:

• keep ignored errors narrow and intentional
• reduce accidental hiding of real bugs
• make future maintenance easier
• encourage proper typing instead of broad suppression

Common directives

TypeScript commonly uses these directives:

// @ts-ignore

Ignores errors on the next line.

// @ts-expect-error

Suppresses the next-line error, but also reports a problem if no error actually exists. This is safer when you expect a known issue.

// @ts-nocheck

Disables type checking for the entire file when placed near the top.

// @ts-check

Enables type checking in JavaScript files.

In real programming, broad suppression should be a last resort. Most of the time, a better type annotation or a small refactor is the better solution.

Think of TypeScript as a proofreader.

• @ts-ignore is like telling the proofreader: "Skip checking the next sentence."
• @ts-expect-error means: "I know the next sentence looks wrong; skip it, but warn me if it ever becomes correct."
• @ts-nocheck means: "Do not review this whole document."

There is no built-in version that means: "Ignore this paragraph only."

If you want to skip a whole paragraph, you either:

• mark each sentence individually, or
• move that paragraph into its own file and disable checking for that file

That is why TypeScript does not provide block-level @ts-ignore. It wants you to be precise about what is being skipped.

Core syntax

Ignore the next line

// @ts-ignore
const result: number = "hello";

TypeScript skips the error on the const result... line.

Expect an error on the next line

// @ts-expect-error
const result: number = "hello";

This is often better than @ts-ignore because TypeScript will complain if that line stops producing an error later.

Disable checking for a whole file

// @ts-nocheck

const value: number = "hello";
const user = unknownFunction();
user.missingMethod();

This disables type checking for the entire file.

Example: trying to ignore a block

This does not exist:

// Not valid TypeScript behavior
// @ts-ignore-start
const a: number = "x";
const b: string = 123;
// @ts-ignore-end

TypeScript has no @ts-ignore-start or @ts-ignore-end directive.

What to do instead

Option 1: ignore each line

// @ts-ignore
const a: number = "x";

// @ts-ignore
const b: string = 123;

Option 2: fix the types

const a: string = "x";
const b: number = 123;

Option 3: isolate legacy or unsafe code in another file

// legacy-code.ts
// @ts-nocheck

export function runLegacyThing(data) {
  return data.oldField + data.otherField;
}

This approach is sometimes used when migrating older JavaScript to TypeScript.

Better example with type assertion

Instead of ignoring an error, you may be able to tell TypeScript what the type is:

const input = document.getElementById("name") as HTMLInputElement;
console.log(input.value);

This is often cleaner than suppressing the error.

Consider this example:

function printLength(value: string | null) {
  // @ts-ignore
  console.log(value.length);

  console.log("done");
}

Step by step

1. TypeScript reads the function definition.
2. It sees value: string | null.
3. On the next line, value.length may be unsafe because value could be null.
4. The // @ts-ignore directive tells TypeScript to suppress the error for that one next line only.
5. The following line, console.log("done"), is checked normally.

Key takeaway

Only this line is ignored:

console.log(value.length);

This line is not affected by the earlier directive:

console.log("done");

Safer version without ignoring

function printLength(value: string | null) {
  if (value === null) {
    console.log("No value");
    return;
  }

  console.log(value.length);
  console.log("done");
}

Now TypeScript understands that after the null check, value must be a string.

Developers usually want broader suppression in situations like these:

Migrating old JavaScript to TypeScript

A file may contain many dynamic patterns that TypeScript cannot understand yet. In that case, teams sometimes use // @ts-nocheck temporarily at the top of the file.

Interacting with untyped third-party libraries

If a library has poor or missing type definitions, one or two lines may need @ts-ignore or @ts-expect-error until proper typings are added.

Writing test cases for invalid input

Sometimes you intentionally write code that should be type-invalid to test validation logic.

// @ts-expect-error
createUser(123);

Gradual refactoring

A large codebase may isolate legacy code in one file with @ts-nocheck while new code remains fully typed.

DOM or platform-specific APIs

When TypeScript cannot infer the exact runtime type, developers may prefer a type assertion over suppression.

const canvas = document.getElementById("chart") as HTMLCanvasElement;

In real projects, developers try to keep suppression narrow and documented.

Common patterns

Prefer @ts-expect-error over @ts-ignore

This is useful when a line is intentionally invalid.

// @ts-expect-error - testing invalid input on purpose
sendEmail(null);

If the line later becomes valid, TypeScript alerts you that the directive is no longer needed.

Use guard clauses instead of suppression

function getUpperName(name: string | undefined) {
  if (!name) return "UNKNOWN";
  return name.toUpperCase();
}

This is cleaner than ignoring a possible undefined error.

Use validation before unsafe access

function parseAge(value: unknown) {
  if (typeof value !== "number") {
    throw new Error("Age must be a number");
  }

  return value;
}

Wrap legacy code

Teams often isolate hard-to-type logic behind a typed wrapper.

// legacy.ts
// @ts-nocheck
export function readLegacyConfig(file) {
  return someOldParser(file);
}

// config.ts
import { readLegacyConfig } from "./legacy";

export function loadConfig(path: string): { port: number } {
  const data = readLegacyConfig(path);
  return { port: Number(data.port) };
}

Replace ignores with explicit types

type ApiResponse = {
  id: number;
  name: string;
};

const data: ApiResponse = await response.json();

This improves maintainability compared with repeated suppression comments.

1. Expecting @ts-ignore to affect multiple lines

Broken expectation:

// @ts-ignore
const a: number = "x";
const b: string = 123;

Only the first assignment is ignored. The second line is still checked.

Fix

Add a directive per line, or use a better type-based solution.

// @ts-ignore
const a: number = "x";

// @ts-ignore
const b: string = 123;

2. Using @ts-ignore when @ts-expect-error is better

// @ts-ignore
createUser(123);

If this line later becomes valid, the ignore stays silently. That can hide cleanup opportunities.

Better

// @ts-expect-error
createUser(123);

3. Hiding real bugs instead of fixing types

Broken code:

function greet(name?: string) {
  // @ts-ignore
  return name.toUpperCase();
}

This can crash at runtime when name is undefined.

Better

function greet(name?: string) {
  if (!name) return "HELLO";
  return name.toUpperCase();
}

4. Using @ts-nocheck too broadly

Disabling checks for a whole file can hide many unrelated problems.

Avoid this unless necessary

• legacy migration files
• generated code
• temporary integration code with clear follow-up work

5. Forgetting that comment placement matters

Broken example:

const a = 1;
// @ts-ignore
const b: number = "text";

This works only because the directive is immediately before the ignored line. If another line appears in between, it will not affect the intended statement.

6. Suppressing errors caused by missing type definitions

Sometimes the real fix is installing or writing types rather than ignoring the error.

Examples:

• adding library type packages
• defining interfaces
• using declare statements where appropriate

@ts-ignore vs @ts-expect-error

• Use @ts-ignore when you must suppress a line and cannot easily express the types.
• Use @ts-expect-error when the error is intentional and should continue to exist.

@ts-ignore vs @ts-nocheck

• @ts-ignore is narrow.
• @ts-nocheck is broad.
• Prefer narrow suppression whenever possible.

Suppression vs fixing types

In most production code, fixing the type information is better because it preserves TypeScript's value: catching bugs before runtime.

Quick reference

Ignore one line

// @ts-ignore
someProblematicCode();

Expect one line to error

// @ts-expect-error
someProblematicCode();

Disable whole file

// @ts-nocheck

Place it near the top of the file.

Rules

• @ts-ignore affects only the next line.
• There is no block version of @ts-ignore.
• For multiple lines, repeat the directive or restructure the code.
• For a whole file, use @ts-nocheck.
• Prefer @ts-expect-error when the error is intentional.
• Prefer fixing the types instead of suppressing errors.

Safer alternatives

• add proper type annotations
• use union narrowing with if
• use type assertions carefully
• define interfaces for external data
• isolate legacy code in a separate file

Good rule of thumb

1. First try to fix the type.
2. If the error is intentional, use @ts-expect-error.
3. If absolutely necessary, use @ts-ignore.
4. Use @ts-nocheck only for special cases.

Can @ts-ignore ignore multiple lines in TypeScript?

No. It only suppresses errors on the next line.

Is there a block version like @ts-ignore-start and @ts-ignore-end?

No. TypeScript does not provide block-level ignore directives.

How do I disable TypeScript checking for a whole file?

Use // @ts-nocheck near the top of the file.

Should I use @ts-ignore or @ts-expect-error?

Use @ts-expect-error when you intentionally expect a type error. It is safer because TypeScript warns you if the error disappears later.

Why is block-level ignore not supported?

Because broad suppression can hide unrelated bugs. TypeScript encourages precise, line-level suppression.

What is the safest alternative to @ts-ignore?

Usually, the safest option is to rewrite the code so TypeScript can understand the types, such as adding checks, annotations, or interfaces.

Can I use @ts-ignore in JavaScript files?

TypeScript directives can also affect checked JavaScript files, especially when using // @ts-check or TypeScript tooling.

• Type narrowing — helps TypeScript understand values after checks like if (value !== null).
• Type assertions — useful when you need to tell TypeScript a more specific type.
• Union types — many ignored errors come from values that can be one of several types.
• Null and undefined checks — a common source of TypeScript errors that should usually be handled explicitly.
• Compiler directives — @ts-ignore, @ts-expect-error, and @ts-nocheck are all directive comments.
• Type definitions — missing or incorrect typings often lead developers to overuse suppression comments.
• Legacy code migration — file-level suppression is often used temporarily during TypeScript adoption.