Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Type Inference  ›  Capstone Project

Compiler Options That Matter

Compiler Options 12 minA few compiler options decide most of TypeScript's behaviour: strict for how hard it checks, target and module for what JavaScript it writes, and noEmit or noEmitOnError for when it writes files.

Compiler Options That Matter

tsc --init lists well over a hundred options, and it is easy to feel you must understand them all. You do not. A handful decide almost everything about how your project is checked and what JavaScript comes out.

The rule

strict decides how hard it checks; target and module decide what it writes.

How hard it checks — strict. One switch that turns on a family of checks. The two you will feel most:

  • strictNullChecks — null and undefined are no longer silently allowed in every type. A function that might return nothing must say so, and callers must handle it.
  • noImplicitAny — a value whose type cannot be inferred, like an unannotated parameter, is an error instead of quietly becoming any.
function findTask(tasks: Task[], id: number) {
  return tasks.find(t => t.id === id); // Task | undefined
}
findTask(all, 3).title; // strict: error, the task may be undefined

Without strict mode that last line compiles and crashes at runtime when no task matches.

What it writes — target and module.

  • target — the JavaScript version to output, such as ES2022. With an older target, newer syntax is rewritten into older equivalents. It also picks a default set of built-in type declarations (lib), which decides whether methods like Array.prototype.at are known to exist.
  • module — the module system of the output, such as NodeNext for modern Node.js or ESNext for bundlers.

Whether it writes at all.

  • noEmit — check only, write no files. Common when a bundler or runner produces the JavaScript and tsc is used purely as a checker.
  • noEmitOnError — write nothing if there are type errors.

The shortcut

For any option, sort it into one of three questions: "How strict? What output? Output at all?" Most settings you will ever touch answer one of those.

Configuring the task trackerStep 1 of 4
  1. How strict?

    New project, so "strict": true from day one. Turning it on later means fixing many errors at once.

A trap: target does not add missing features at runtime. Setting a new target lets you use Array.prototype.at in types, but if the environment running the code lacks it, the call still fails.

Drills

Answer fast — trust the rule.

quick drill

Which option makes null and undefined stop fitting into every type?

quick drill

With noImplicitAny on, what happens to function add(a, b) { return a + b; }?

quick drill

A bundler builds your JavaScript and you only want tsc to check types. Which option fits?

quick drill

What does the target option mainly control?

quick drill

With strict on, tasks.find(...) returns Task | undefined. What must you do before reading .title?

Remember

  • strict decides how hard it checks; target and module decide what it writes.
  • Sort every option into: how strict, what output, output at all.
  • Trap: a newer target does not make missing runtime features appear.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainWhy turn on strict?

A new project was created with strict: false. Explain what strict: true would change, using at least two of the checks it enables, and whether you would turn it on.