TS7006: Parameter 'x' implicitly has an 'any' type

The exact error string

function greet(name) {
  return `Hello, ${name}`;
}
// error TS7006: Parameter 'name' implicitly has an 'any' type.

const data = JSON.parse(raw);
const names = data.map((item) => item.name);
// error TS7006: Parameter 'item' implicitly has an 'any' type.

TypeScript's job is to know the type of every value. When a parameter has no annotation, TypeScript tries to infer one from context — and when there's no context to infer from, it would have to fall back to any, which disables type-checking for that value entirely. The noImplicitAny flag (on by default in strict mode) turns that silent fallback into the TS7006 error, so the untyped value can't slip through unnoticed.

Fix 1: annotate the parameter

The direct fix, and the right one for a standalone function, is to state the type:

// ❌ name is implicitly any
function greet(name) { return `Hello, ${name}`; }

// ✅ annotate it
function greet(name: string) { return `Hello, ${name}`; }

Fix 2: type the source so callbacks infer for free

This is the subtler and more important case. Callback parameters usually don't need annotations — TypeScript infers them from the array or function they belong to. TS7006 shows up when that source is itself untyped:

// ❌ JSON.parse returns any, so data is any, so item is implicitly any
const data = JSON.parse(raw);
const names = data.map((item) => item.name);

// ✅ type the parsed data at its source — now item is inferred as User
interface User { id: number; name: string; }
const data: User[] = JSON.parse(raw);
const names = data.map((item) => item.name);   // item: User, no annotation needed

Notice the fix is on data, not on item. Annotating the callback parameter directly ((item: User) =>) also silences the error, but typing the source is better: it makes every downstream use of data type-safe, not just this one callback. Because JSON.parse returns any, parsed API responses are the single most common origin of TS7006 in real codebases — give the parsed value a real interface and a cascade of implicit-any errors disappears at once. Need that interface fast? Paste a sample response into JSON to TypeScript and it generates the type for you.

Fix 3: event handlers need their event type

A handler defined standalone has nothing to infer its parameter from:

// ❌ e is implicitly any
const onClick = (e) => console.log(e.clientX);

// ✅ annotate with the DOM event type
const onClick = (e: MouseEvent) => console.log(e.clientX);

// ✅ or attach inline, where the element supplies the type contextually
button.addEventListener("click", (e) => console.log(e.clientX));  // e: MouseEvent

In React, the equivalents are the framework's synthetic event types — React.ChangeEvent<HTMLInputElement>, React.MouseEvent, and so on — or, again, writing the handler inline on the JSX element so the prop's type provides the event type for you.

Fix 4: destructured parameters (TS7031's cousin)

Destructuring a parameter with no object type gives the same class of error (often reported as the closely related TS7031):

// ❌ the destructured object has no type
function render({ id, name }) { /* ... */ }

// ✅ type the whole parameter object
function render({ id, name }: { id: number; name: string }) { /* ... */ }

// ✅ or with a named interface
interface Props { id: number; name: string; }
function render({ id, name }: Props) { /* ... */ }

What NOT to do: disabling noImplicitAny

It's tempting to make the error vanish by setting "noImplicitAny": false — don't. That doesn't fix anything; it just re-hides every untyped parameter as any, which is most of the reason to use TypeScript in the first place. If you're migrating a large JavaScript codebase and need to move incrementally, annotate the specific parameter as x: any explicitly. That silences TS7006 for that one spot, documents that the any is deliberate, and keeps the check on everywhere else so you can tighten types file by file.

Related noImplicitAny errors

Debugging checklist

• ✓ Standalone function? Annotate the parameter directly
• ✓ Callback on an array/function? Type the source, not the callback param
• ✓ Came from JSON.parse or an untyped API? Give the parsed value an interface
• ✓ Event handler? Add the DOM/React event type, or attach it inline
• ✓ Destructured param? Type the whole object (or use a named interface)
• ✓ Migrating from JS? Annotate x: any explicitly — never turn off noImplicitAny