TypeScript — TS7006: Parameter implicitly has an any type

Fix implicit any errors by annotating parameters or providing enough contextual type from call sites.

beginnerdebuggingtypescript

Symptoms

error TS7006: Parameter 'e' implicitly has an 'any' type
Arrow function parameters in callbacks warn
The error appears after enabling noImplicitAny
Destructured callback arguments lack types

Possible causes

A callback parameter has no annotation and the library does not provide a contextual type
noImplicitAny or strict was enabled, surfacing previously silent anys
A generic or overloaded function cannot infer the parameter type
An untyped third-party module provides no types

Diagnosis steps

Annotate the parameter explicitly

onClick((e: MouseEvent) => ...)

Interpretation

An explicit type resolves the error immediately and documents the expected shape.

Install type definitions for the library

npm i -D @types/<lib>

Interpretation

A library without bundled types provides no contextual typing, so the parameter default is any.

Check the strict setting

grep -n "noImplicitAny" tsconfig.json

Interpretation

Knowing whether the flag was just enabled explains why errors appeared suddenly.

Root cause

The parameter has no annotation and no contextual type to infer from, so TypeScript would have to assume any. Under strict settings that is an error rather than a silent default.

Fix

Add explicit parameter types where inference cannot help, install @types packages for untyped libraries, and use well-typed wrappers rather than loosening strictness.

Verify the fix

Rerun the type checker and confirm the error is gone, and confirm autocomplete and type checking work for the now-typed parameter.

Symptom walkthrough

The compiler reports TS7006 for a parameter that implicitly has type any. It commonly appears in callbacks whose library provides no contextual type, or right after enabling noImplicitAny, which surfaces anys that were previously silent. The warning is a reminder that the parameter needs a type so the compiler can check uses of it.

Fix in practice

Annotate the parameter, letting contextual types from well-typed libraries do the work where possible. For untyped dependencies, install the corresponding @types package. Prefer these remedies over turning off strictness, which would reintroduce the silent anys elsewhere.

Verification

Rerun the type checker and confirm the error disappears, then confirm that autocomplete and error checking now work for the parameter. Working type information, not just a passing check, is the goal. Typing a parameter once also improves every later use of that callback in the same module.

Diagnostic commands

Check the behavior with commands like these:

onClick((e: MouseEvent) => ...)
npm i -D @types/<lib>
grep -n "noImplicitAny" tsconfig.json