explicitAnys

Reports explicit uses of the any type.

✅ This rule is included in the ts logical and logicalStrict presets.

The any type in TypeScript is a dangerous “escape hatch” from the type system. Using any disables many type checking rules and is generally best used only as a last resort or when prototyping code.

When a value is typed as any:

• Any property can be accessed without checks
• Any method can be called without verification
• It can be assigned to any other type
• Type errors propagate silently through the codebase

Preferable alternatives to any include:

• If the type is known, describing it in an interface or type
• If the type is not known, using the safer unknown type

Note

TypeScript’s --noImplicitAny compiler option reports implied anys, but doesn’t detect explicit anys the way this rule does.

Examples

❌ Incorrect

const value: any = getResponse();

function process(input: any): void {
  console.log(input.property);
}

function getData(): any {
  return fetchData();
}

✅ Correct

const value: unknown = getResponse();

function process(input: unknown): void {
  if (typeof input === "object" && input !== null && "property" in input) {
    console.log(input.property);
  }
}

interface Data {
  property: string;
}

function getData(): Data {
  return fetchData();
}

Options

This rule is not configurable.

Alternatives to any

If you do know the properties that exist on an object value, it’s generally best to use an interface or type to describe those properties. If a straightforward object type isn’t sufficient, then you can choose between several strategies instead of any. The following headings describe some of the more common strategies.

unknown

If you don’t know the data shape of a value, the unknown type is safer than any. Like any, unknown indicates the value might be any kind of data with any properties. Unlike any, unknown doesn’t allow arbitrary property accesses: it requires the value be narrowed to a more specific type before being used. See The unknown type in TypeScript for more information on unknown.

Index Signatures

Some objects are used with arbitrary keys, especially in code that predates Maps and Sets. TypeScript interfaces may be given an “index signature” to indicate arbitrary keys are allowed on objects.

For example, this type defines an object that must have an apple property with a number value, and may have any other string keys with number | undefined values:

interface AllowsAnyStrings {
  apple: number;
  [i: string]: number | undefined;
}

let fruits: AllowsAnyStrings;

fruits = { apple: 0 }; // Ok
fruits.banana = 1; // Ok
fruits.cherry = undefined; // Ok

See What does a TypeScript index signature actually mean? for more information on index signatures.

Union Types

Some values can be one of multiple types. TypeScript allows representing these with “union” types: types that include a list of possible shapes for data.

Union types are often used to describe “nullable” values: those that can either be a data type or null and/or undefined. For example, the following StringLike type describes data that is either a string or undefined:

type StringLike = string | undefined;

let fruit: StringLike;

fruit = "apple"; // Ok
fruit = undefined; // Ok

See TypeScript Handbook: Everyday Types > Union Types for more information on union types.

Type Parameter Constraints

“Generic” type parameters are often used to represent a value of an unknown type. It can be tempting to use any as a type parameter constraint, but this is not recommended.

First, extends any on its own does nothing: <T extends any> is equivalent to <T>. See unnecessaryTypeConstraints for more information.

Within type parameters, never and unknown otherwise can generally be used instead. For example, the following code uses those two types in AnyFunction instead of anys to constrain Callback to any function type:

type AnyFunction = (...args: never[]) => unknown;

function curry<Greeter extends AnyFunction>(greeter: Greeter, prefix: string) {
  return (...args: Parameters<Greeter>) => `${prefix}: ${greeter(...args)}`;
}

const greet = (name: string) => `Hello, ${name}!`;
const greetWithDate = curry(greet, "Logged: ");

greetWithDate("linter"); // => "Logged: Hello, linter!"

See When to use never and unknown in TypeScript for more information on those types.

When Not To Use It

any is always a dangerous escape hatch. Whenever possible, it is always safer to avoid it. TypeScript’s unknown is almost always preferable to any.

However, there are occasional situations where it can be necessary to use any. Most commonly:

• If your project isn’t fully onboarded to TypeScript yet, any can be temporarily used in places where types aren’t yet known or representable
• If an external package doesn’t yet have typings and you want to use any pending adding a .d.ts for it
• You’re working with particularly complex or nuanced code that can’t yet be represented in the TypeScript type system

You might consider using Flint disable comments and/or configuration file disables for those specific situations instead of completely disabling this rule.

Further Reading

• TypeScript Handbook: any type
• TypeScript Release Notes: unknown

Equivalents in Other Linters

• Biome: noExplicitAny
• Deno: no-explicit-any
• ESLint: @typescript-eslint/no-explicit-any
• Oxlint: typescript/no-explicit-any