Prevent accidental implicit any
Enforce explicit types for unannotated parameters and declarations in new modules.
TypeScript · Const
noImplicitAny
noImplicitAny makes TypeScript report errors when it would infer any because a value lacks an annotation or usable contextual type. Enable it in compilerOptions to prevent accidental loss of type checking.
How it works
Enable this compiler option to make TypeScript report locations where it would otherwise infer the type any. In large codebases, annotate those values or provide enough contextual typing to preserve static checking instead of silently accepting unchecked operations.
Syntax
{"compilerOptions":{"noImplicitAny":true}}Parameters
| Name | Type | Description |
|---|---|---|
noImplicitAny | boolean | Boolean compiler option. When true, reports declarations and expressions whose type would otherwise be inferred as any. |
Key points
- The option addresses cases where missing annotations leave TypeScript unable to infer a more specific type.
- Implicit any can hide invalid member access and other mistakes because the unchecked value accepts operations that a known type would reject.
- Enabling the flag converts an otherwise silent fallback into a compiler diagnostic.
- The diagnostic identifies the specific declaration whose type was not inferred.
- The setting is a compiler flag and is enabled in project configuration under compilerOptions.
Common mistakes
- The option reports implicit any in places where inference cannot determine a type; an untyped function parameter is a common example.
- An explicitly written any is different from an implicit any; this option targets the latter.
Example: Enable noImplicitAny
{
"compilerOptions": {
"noImplicitAny": true
}
}
function formatUser(id) {
return `User ${id}`;
}With noImplicitAny enabled, the unannotated parameter causes a compile-time error; add an explicit type to make the function valid.
When to use it
Catch hidden type errors
Detect unchecked member access that would otherwise compile through an inferred any.
Improve large-codebase safety
Adopt stronger checking incrementally by enabling the option in a project configuration.
Interview questions
QWhat does noImplicitAny do?
It reports an error whenever TypeScript would infer any because no annotation or contextual type determines the value's type. This prevents unchecked operations from passing silently.
Follow-up: How can a project enable the related strictness settings together? Set strict to true, then opt out of individual strictness flags when necessary.
QWhat is a typical diagnostic caused by noImplicitAny?
A parameter such as function fn(s) can receive an implicit any error when TypeScript cannot infer s. Giving s an explicit type resolves that diagnostic and restores checking for operations on it.
Follow-up: What happens if the parameter is explicitly declared as any? The explicit annotation is intentional and is not an implicit-any inference diagnostic.
QHow do you enable noImplicitAny?
The setting belongs in compilerOptions in tsconfig.json, where it can be enabled with a boolean value. It can also be enabled through the corresponding compiler command-line option.
Follow-up: Why is this useful in a large codebase? It turns accidental loss of type information into an actionable compile-time error.
Related
strictstrictNullChecksnoImplicitThisany