How to Fix TypeScript Error ts(7006): Parameter 'x' implicitly has an 'any' type

beginner๐Ÿ”ต TypeScript2026-03-29| TypeScript 2.0+, VS Code, Node.js environment with tsconfig.json enabled.

Error Message

Parameter 'x' implicitly has an 'any' type. ts(7006)
#typescript#web-development#programming-tips#tsconfig

TL;DR: The Quick Fix

The fastest way to clear this error is to tell TypeScript exactly what kind of data your function expects. Add a type annotation directly to the parameter in your function signature.

// โŒ Error: Parameter 'name' implicitly has an 'any' type. ts(7006)
function greet(name) {
  console.log("Hello, " + name);
}

// โœ… Fix: Add an explicit type
function greet(name: string) {
  console.log("Hello, " + name);
}

Why is TypeScript complaining?

You are seeing this error because the noImplicitAny flag is active in your tsconfig.json. This setting is often turned on automatically when you enable "strict": true. TypeScript's job is to catch type-related bugs before they reach your users. When you leave a parameter untyped, the compiler doesn't want to guess what it is, so it defaults to any and throws a warning to keep your code safe.

Common scenarios and how to solve them

1. Arrow Functions

Standard arrow functions are a frequent source of this error. You can fix them by adding a colon and the type right after the parameter name.

// Define the input types and the return type for clarity
const calculateTax = (price: number, taxRate: number): number => {
  return price * taxRate;
};

2. Destructured Objects

Handling objects in arguments can get messy. Instead of typing the individual properties inside the curly braces, define the shape of the entire object using an interface or type.

// โŒ Error: 'id' and 'email' will trigger ts(7006)
const sendWelcomeEmail = ({ id, email }) => {
  // logic here
};

// โœ… Fix: Use an interface
interface UserAccount {
  id: number;
  email: string;
}

const sendWelcomeEmail = ({ id, email }: UserAccount) => {
  console.log(`Sending email to ID: ${id}`);
};

3. Callback Functions in Array Methods

Usually, TypeScript is smart enough to infer types in .map() or .filter(). However, if your starting array isn't typed properly, the callback parameter loses its context. Ensure your source data has a clear type definition.

// If 'products' is just an empty array [], TS won't know what 'p' is
interface Product {
  slug: string;
  price: number;
}

const products: Product[] = [{ slug: 'keyboard', price: 99 }];

// Now 'p' is automatically recognized as a Product
const slugs = products.map(p => p.slug);

Updating your Compiler Configuration

If you are migrating a massive JavaScript codebase to TypeScript, these errors can be overwhelming. You can temporarily silence them in your tsconfig.json, though this should be a last resort. Disabling this check essentially turns off one of TypeScript's best safety features.

  • Open your tsconfig.json file.
  • Locate the compilerOptions object.
  • Set noImplicitAny to false.
{
  "compilerOptions": {
    "noImplicitAny": false,
    "strict": false 
  }
}

Note: In a professional production environment, it is much better to keep this setting true to prevent undefined errors at runtime.

The "Escape Hatch": Using any

Sometimes you really don't know what the data will be, such as when working with a chaotic third-party API. In these cases, you can explicitly label the parameter as any. This satisfies the compiler because you are making a conscious choice rather than letting TypeScript guess.

function logExternalData(payload: any) {
  console.log("External data received:", payload);
}

How to verify your changes

Once you've added your types, verify the fix using these tools:

  • VS Code Problems Tab: Press Cmd+Shift+M (Mac) or Ctrl+Shift+M (Windows). The list should be empty.
  • The CLI Check: Run npx tsc --noEmit in your terminal. This checks your entire project for type errors without generating any output files.

Wrapping Up

Think of the ts(7006) error as a helpful reminder rather than a roadblock. By explicitly defining your types, you make your code easier for other developers to read and much harder to break. Avoid disabling the strict check in your config unless you are dealing with a legacy project that is too large to fix all at once.

Related Error Notes