TypeScript Gotcha #1: The any Escape Hatch That Always Bites Back

Meta: "TypeScript's any type feels like a quick fix but silently disables type safety. Here's what it actually costs you in production and how to stop the spread."

I

The PR is blocking a deploy. Four engineers are waiting. The deadline was this morning. The type error is cryptic something about a generic constraint in a third-party library that nobody has time to untangle right now and there's a production bug queued behind this that actually matters.

Untitled
Copy
1const response = await fetchOrder(id) as any;

Tests pass. PR merges. Deploy ships. Everyone goes home.

That line is still in production six months later. So are the twelve lines that referenced it, each one also typed as any because they had to work with the original. And now there's a runtime error in a function three hops away that TypeScript couldn't warn you about, because at the point the type information was needed, it had already been discarded.

This is how typescript any type problems actually develop. Not from one bad decision, but from a pattern that normalizes itself.

What any Actually Does

TypeScript's type system is a compile-time check. It looks at your code before it runs and says: "this function expects a string, but you're passing a number that's going to fail." Catch it now, not at 2am when a user hits it.

any opts a value out of that system entirely. When you type something as any, TypeScript stops checking it. You can call any method on it. Pass it anywhere. Index it with anything. The compiler will not object. You've told it: "trust me, I know what this is."

The problem is that any is contagious. If a function returns any, every variable that holds the return value is also any. Every function that receives that variable operates without type safety. The type hole grows outward from where it was introduced.

Untitled
Copy
1function parseConfig(raw: any) {
2  return {
3    timeout: raw.timeout,   // any
4    retries: raw.retries,   // any
5    endpoint: raw.endpoint  // any
6  };
7}
8
9const config = parseConfig(data);
10// config.timeout is any
11// config.timeout.toFixed(2) no error from TypeScript
12// but if timeout is actually a string in production, this throws at runtime

TypeScript catches none of this. You've opted out.

Why It Spreads

The first any is usually reluctant. The tenth is habit.

Once a team has a few any usages in the codebase, two things happen. The friction of adding another drops it's not "introducing a bad practice", it's "consistent with how we've been doing it." And the return on investment of TypeScript starts declining, because the parts of the codebase that interact with untyped values multiply.

This is the velocity cost that's hard to measure. TypeScript's value is in autocomplete, refactoring safety, and jump-to-definition accuracy. All three degrade when values are any. When you rename a field, TypeScript finds all the references it needs to update except the ones typed as any, which compile fine and break at runtime. The refactor that should take 20 minutes takes an afternoon, plus a production bug.

Technical debt is usually described in terms of features that take longer to build. any is a quieter version: it makes every feature slightly less safe and every refactor slightly more dangerous, across the entire surface area it touches.

What Actually Breaks in Production

The failures that come from unchecked any values tend to be one of three kinds.

Runtime type errors on properties that don't exist. The API response changed shape a field was renamed, a nested object was flattened. If the response was typed correctly, TypeScript would have caught every callsite that used the old field name. If it was typed as any, the code compiles fine. The error shows up when a user hits the code path that accesses the renamed field.

Incorrect numeric operations on values that are actually strings. This is especially common with API responses that return numeric-looking values as strings a problem that shows up regularly when integrating with older Indonesian fintech APIs that serialize everything as strings for compatibility reasons. "42" + 8 is "428", not 50. TypeScript knows this. But only if the type isn't any.

Silent data corruption when passing any values into functions that expect specific shapes. No error is thrown. The wrong data propagates through the system and surfaces in a form that's hard to trace back to the origin.

The Part Most Teams Get Wrong

There are two different settings, and most teams conflate them.

noImplicitAny a TypeScript compiler option prevents TypeScript from inferring any when it can't determine a type. It errors on things like:

Untitled
Copy
1function process(data) { // Error: 'data' implicitly has 'any' type
2  return data.value;
3}

no-explicit-any an ESLint rule prevents you from writing any explicitly. It catches:

Untitled
Copy
1const response = await fetch(url) as any; // ESLint error

Most teams enable noImplicitAny and think they've solved the problem. They haven't. Explicit any the kind you type with intent is still fully allowed. And explicit any is almost always the worse kind, because someone made an active choice to disable the type checker rather than it happening by omission.

You need both. noImplicitAny: true in your tsconfig.json, and @typescript-eslint/no-explicit-any: error in your ESLint config. The TypeScript compiler option catches accidental any. The ESLint rule catches deliberate any.

The legitimate uses of any are narrow: writing utility types, certain generic constraint scenarios, and controlled integration points with genuinely untyped external systems. In those cases, the convention is to isolate the any at the boundary, validate and cast to a proper type immediately, and export only the typed version. The any never leaves the integration layer.

If you want the full setup including how noImplicitAny, strictNullChecks, and the ESLint rules fit together the TypeScript project setup guide covers this as part of a complete configuration.

FAQ

Q: What should I use instead of any when I genuinely don't know the type? A: Use unknown. It forces you to check the type before using the value TypeScript won't let you call methods on unknown without a type guard. It's the honest version of "I don't know what this is yet." any is the dishonest version: it claims to know, but does nothing to verify.

Q: We have a large existing codebase full of any. Where do we start? A: Start with the ESLint rule in warn mode, not error mode. This surfaces every explicit any without blocking the build. Then tackle the high-traffic paths first the functions that are called most often, or that process the most critical data. Don't try to fix everything at once. Fix the parts where a runtime error causes the most damage.

Q: Third-party libraries sometimes force any because their types are wrong or missing. What then? A: Two options. First, check if there's a @types/ package for the library community-maintained types fix a lot of this. Second, write a thin wrapper that takes unknown, validates the shape (with a library like zod or a manual type guard), and returns a typed value. The any lives inside the wrapper, the typed interface is what the rest of your codebase sees.

Q: Is any ever acceptable? A: In generated code, at controlled integration boundaries with proper validation immediately after, and in specific generic utility types. Outside those cases, it's a smell. The bar for using explicit any should be: "I can explain in a code comment exactly why the type system can't handle this correctly, and why fixing the types would cost more than this tradeoff is worth." If you can't write that comment, you shouldn't use any.

Q: How do we prevent new any from being added as the team grows? A: Code review helps but doesn't scale. The ESLint rule in error mode is the only reliable enforcement it fails the CI pipeline rather than depending on a reviewer catching it. Set the rule, document the exception process (a specific ESLint disable comment with a required explanation), and make the exception process slightly annoying. The friction is the point.

The any type doesn't feel dangerous when you use it. That's what makes it dangerous. TypeScript is supposed to be the system that catches mistakes before they reach production and any is the instruction to stop checking.

Every team we've worked with that had persistent runtime type errors had significant any coverage in the codebase. That's not a coincidence.

Internal links used:

• TypeScript project setup guide full configuration context including the relevant compiler and ESLint options
• `` companion gotcha on strict mode migration, not yet published

External links used:

• None

Word count: ~1,250

Self-Review Scorecard