ProgramGuru

noImplicitAny

noImplicitAny — why it matters

noImplicitAny reports locations where the compiler would otherwise infer the unsafe any type without an explicit annotation. Function parameters, callbacks without contextual types, and loosely declared variables are common examples. Prefer specific types or unknown at an external-data boundary.

What you’ll learn

  • Explain noimplicitany and the problem it solves.
  • Identify the relevant compile-time checks and runtime responsibilities.
  • Run the example, predict its output, and try a realistic modification.

Understand the mechanism

Both parameters have explicit numeric types; the return type remains numeric. Removing the annotation from percent produces an implicit-any diagnostic with noImplicitAny.

Annotating everything as any makes the errors disappear but forfeits the guarantees that motivated the option.

Follow the concept flow

noImplicitAny — concept flowUnannotated parameter → Compiler detects implicit any → Add useful annotationnoImplicitAny1Unannotated parameter2Compiler detects implicitany3Add useful annotationCompiler configuration changes checks and output, not runtime guarantees.
Follow the responsibilities from input to checked result.

Run the primary TypeScript example

Save as noimplicitany.ts. The following program passed strict TypeScript compilation, and the displayed output was captured by executing its emitted JavaScript with Node.js 22.16.0.

TypeScript source

function discount(price: number, percent: number): number {
  return price * (1 - percent / 100);
}
console.log(discount(100, 15).toFixed(2));

Verified output

85.00

Compile: npx tsc --strict --target es2022 --module commonjs noimplicitany.ts; run: node noimplicitany.js. For Node.js API examples, install @types/node first. For browser projects, use the browser-specific instructions below.

The example demonstrates the code-level behavior; the related configuration or test commands are shown separately when needed.

Trace the result

Both parameters have explicit numeric types; the return type remains numeric. Removing the annotation from percent produces an implicit-any diagnostic with noImplicitAny.

Predict what changes if you alter one input. Then run the code to compare your reasoning with the real output.

Common mistake and correction

Annotating everything as any makes the errors disappear but forfeits the guarantees that motivated the option.

Identify whether the failure is a type-checking issue, a configuration issue, or a runtime behavior issue before choosing a fix.

Practice the concept

Delete one parameter annotation and use tsc --noImplicitAny --noEmit to inspect the diagnostic.

Write down your expected result first. For configuration examples, compare compiler output and diagnostics; for test examples, make the assertion fail deliberately to verify that the tool reports it.

Check your understanding

What should you remember when configuring TypeScript compilation?
Choose one answer. You can try again.

Answer and explanation

Compiler options control static checks or emitted files; running the result is a separate step.

Both parameters have explicit numeric types; the return type remains numeric. Removing the annotation from percent produces an implicit-any diagnostic with noImplicitAny.

Official reference

For the exact current options and platform behavior, consult the official documentation. These examples were verified using the tool versions described above.

What to remember

noImplicitAny reports locations where the compiler would otherwise infer the unsafe any type without an explicit annotation.

Run the primary example, then complete the practice task or environment-specific lab.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: strictFunctionTypes →