How @ts-ignore works for a block: 3 ways in TypeScript

Silence in the editor: why do we need to block TypeScript?

Anyone who has written TypeScript for at least a week has encountered a situation where the compiler starts "yelling" at seemingly working code. You are sure the logic is correct, but tsc or the IDE highlights every other line in red. It is especially painful when this happens inside a single block: a loop, a condition, or a function.

The standard // @ts-ignore only works for the next line. But what if you need to "shut up" the compiler for 10–15 lines at once? Copying the same comment before each line is a dead end. It not only clutters the code but also makes it unreadable.

In this article, we will break down three real approaches to applying @ts-ignore for an entire block in TypeScript. You will learn when each one is appropriate, and when it is better to avoid error suppression altogether. Let's go!

The problem: @ts-ignore only works for one line

Let's start with a basic example. Imagine you are working with dynamic data from an API, where types can change. You have a block of code that will definitely execute, but TypeScript complains about every property access.

// Example: parsing a response from an unreliable API\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // OK, but only one line\n\n// The next line will cause an error again if you don't add // @ts-ignore\n// console.log(data.user.age); // Error: Property 'age' does not exist on type 'object'\n

Writing // @ts-ignore before each line is bad practice. It increases code volume, complicates refactoring, and hides real errors. But there is good news: TypeScript (starting from version 3.9) and the community have come up with several elegant solutions.

Approach 1: @ts-nocheck — brute force for an entire file

The simplest, but also the most radical way is to add // @ts-nocheck at the beginning of the file. This completely disables type checking for the entire file. But we need a block, not the whole file. However, there is a trick: you can extract the problematic block into a separate file and import it.

Pros:

\n
• Solves the problem instantly.
\n
• Suitable for legacy code that you plan to rewrite later.
\n

Cons:

\n
• Disables all type checks in the file. You might miss real bugs.
\n
• Not suitable for large projects with strict linting rules.
\n
• Creates "black boxes" of code.
\n

// bad.ts — file with type checking disabled\n// @ts-nocheck\nexport function processData(data: any) {\n    const result = data.user.name + ' is ' + data.user.age;\n    return result; // No error, even if data is null\n}\n

When to use: Only for temporary scripts or inherited code that you are rewriting. Never use in production without an explicit TODO marker.

Approach 2: ts-expect-error — a smart alternative to @ts-ignore

Starting with TypeScript 3.9, the // @ts-expect-error directive appeared. It works almost like @ts-ignore, but with one important difference: if there is no error, TypeScript will issue a warning. This helps you remember to remove the comment after fixing the code.

But how to apply this to a block? The answer is — not directly. @ts-expect-error also only works for one line. However, we can use a trick with an Immediately Invoked Function Expression (IIFE).

// The block to be ignored is wrapped in an IIFE\n(function() {\n    // @ts-expect-error — we expect an error on the next line\n    const x: number = 'hello'; // Error: Type 'string' is not assignable to type 'number'\n\n    // @ts-expect-error — another expected error\n    con