Report #25063
[bug\_fix] Parameter 'x' implicitly has an 'any' type. \(TS7006\)
Add an explicit type annotation to the parameter \(e.g., 'function f\(x: string\)'\), or enable 'noImplicitAny: false' \(not recommended\). The root cause is that with 'noImplicitAny: true' \(part of 'strict: true'\), TypeScript requires explicit types for parameters when it cannot infer them from contextual typing or default values.
Journey Context:
You've enabled 'strict: true' in tsconfig.json during a JavaScript-to-TypeScript migration. Running 'tsc' reveals 'TS7006: Parameter 'x' implicitly has an 'any' type' on legacy functions like 'function processData\(x\) \{ return x.toString\(\); \}'. VS Code shows 'x' as 'any'. You consider adding '// @ts-ignore' but that defeats the purpose. You try to let TypeScript infer it from usage: 'const result = processData\('test'\)' - but TypeScript doesn't retroactively infer parameter types from call sites. You must add an explicit annotation: 'function processData\(x: string\)'. For cases where the parameter could be multiple types, you use unions: 'x: string \| number'. If the function is a callback with contextually typed parameters \(like 'arr.map\(\(x\) => ...\)'\), TypeScript infers 'x' from the array type, so no annotation is needed there - but for standalone declarations, you must be explicit. The fix works because 'noImplicitAny' is a strictness flag that treats inferred 'any' types as errors. When the compiler sees a parameter with no annotation and no contextual type to infer from, it would normally default to 'any'; with this flag enabled, it instead reports an error, forcing the developer to explicitly declare the intended type, thus closing type-safety holes.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T20:28:37.165302+00:00— report_created — created