Learn why TypeScript throws TS7006 when function parameters lack type annotations under strict mode, and how to add proper types.
TypeScript error TS7006 fires when a function parameter has no type annotation and TypeScript cannot infer its type from context. Under strict mode (or specifically the noImplicitAny compiler option), TypeScript refuses to silently default to any — it wants you to be explicit about what types your functions accept.
This is actually a good thing. The any type turns off type checking entirely for that value, which defeats the purpose of using TypeScript. TS7006 is TypeScript nudging you toward writing safer code.
You will see this error most often when:
The most straightforward case — you wrote a function but forgot to annotate the parameters.
// ❌ Error: Parameter 'name' implicitly has an 'any' type. (TS7006)
function greetUser(name) {
return `Hello, ${name}!`
}// ✅ Add an explicit type annotation
function greetUser(name: string) {
return `Hello, ${name}!`
}When you pass a callback to a function that TypeScript cannot contextually type, you will see TS7006 on the callback parameters.
// ❌ Error: Parameter 'item' implicitly has an 'any' type. (TS7006)
const processItems = (items: string[], callback) => {
return items.map(callback)
}// ✅ Type the callback parameter explicitly
const processItems = (
items: string[],
callback: (item: string, index: number) => string
) => {
return items.map(callback)
}When writing event handlers outside of a framework with strong typings, TypeScript may not know the event type.
// ❌ Error: Parameter 'event' implicitly has an 'any' type. (TS7006)
document.addEventListener('click', function (event) {
// This actually works fine because addEventListener is well-typed,
// but a standalone handler reference won't:
})
const handleClick = (event) => {
// TS7006 here — no context to infer from
console.log(event.target)
}// ✅ Annotate the event type
const handleClick = (event: MouseEvent) => {
console.log(event.target)
}Destructuring in parameters still requires a type annotation on the whole object.
// ❌ Error: Binding element 'title' implicitly has an 'any' type. (TS7006)
function renderCard({ title, description }) {
return `${title}: ${description}`
}// ✅ Type the destructured object
function renderCard({ title, description }: { title: string; description: string }) {
return `${title}: ${description}`
}
// Or better yet, define an interface
interface CardProps {
title: string
description: string
}
function renderCard({ title, description }: CardProps) {
return `${title}: ${description}`
}Identify the parameter — the error message tells you exactly which parameter is untyped. Look for Parameter 'x' implicitly has an 'any' type where x is the parameter name.
Determine the correct type — think about what values this parameter should accept. Check how it is used inside the function body for clues.
Add the type annotation — place the type after the parameter name with a colon: (param: Type).
Use unknown instead of any — if the parameter genuinely accepts any value, prefer unknown over any. This forces you to narrow the type before using it, which is much safer.
// Prefer this when type is truly flexible
function processInput(value: unknown) {
if (typeof value === 'string') {
return value.toUpperCase()
}
return String(value)
}any or unknown.function firstElement<T>(arr: T[]): T | undefined {
return arr[0]
}TS7006 occurs when you have noImplicitAny enabled (or strict mode, which includes it) and a function parameter does not have a type annotation. TypeScript cannot infer the type automatically in these cases, so it raises an error rather than silently falling back to any.
Add an explicit type annotation to the parameter. For example, change (item) to (item: string) or (item: MyType). If the type truly should be flexible, use unknown instead of any — this keeps type safety intact while allowing any value to be passed in.
If you are migrating a large JavaScript codebase and need a temporary escape hatch, you can disable noImplicitAny in your tsconfig.json, but this is not recommended for new projects. A better migration strategy is to add // @ts-expect-error comments temporarily and fix them incrementally.
Get the latest TypeScript tips, tutorials, and course updates delivered straight to your inbox.