Chapter 3 set up tsconfig.json with a lean base configuration. Now, with the whole language knowledge from this tutorial, let's look at the INDIVIDUAL strict flags more closely – WHAT they concretely check, and WHY.

What strict: true actually enables

"strict": true is an UMBRELLA option that enables several INDIVIDUAL flags at once. The most important ones, examined individually:

// strictNullChecks: WITHOUT this flag, the following would be VALID (but dangerous):
function findBook(isbn: string): Book | undefined { /* ... */ return undefined; }
const book = findBook('123');
console.log(book.title); // WITH strictNullChecks: error! book could be undefined
                         // WITHOUT strictNullChecks: no error, potential runtime crash

strictNullChecks is ARGUABLY the most important individual flag – it enforces EXACTLY the kind of checks we've been doing consistently since chapter 6 (optional parameters). WITHOUT this flag, string | undefined would be practically meaningless, since TypeScript would NOT enforce the undefined case.

// noImplicitAny: WITHOUT this flag, the following would be VALID:
function process(data) { // parameter WITHOUT a type -> becomes implicitly 'any'
  return data.something.doThings(); // NO type checking, since 'any'
}
// WITH noImplicitAny (part of strict): error - 'data' needs an explicit annotation

noImplicitAny prevents EXACTLY the problem from chapter 4/5: variables/parameters that SILENTLY become any because no one added an annotation – without this flag, TypeScript would SILENTLY give up on type checking instead of showing an error.

More useful flags outside of strict

{
  "compilerOptions": {
    // ... previous options from chapter 3
    "noUnusedLocals": true,      // error on UNUSED local variables
    "noUnusedParameters": true,  // error on UNUSED function parameters
    "noImplicitReturns": true,   // error if NOT ALL code paths of a function return a value
    "noFallthroughCasesInSwitch": true // error on forgotten 'break' in switch statements
  }
}

These flags are NOT part of strict, but additionally enabled in many professional projects – they catch NO type errors in the strict sense, but common STYLE and LOGIC mistakes TypeScript would technically allow.

tsconfig inheritance with extends

Remember "extends": "expo/tsconfig.base" from "React Native for Professionals" chapter 12? The same principle works for ANY tsconfig.json, including ones you write yourself:

{
  "compilerOptions": {
    "target": "ES2022",
    "strict": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "dist",
    "rootDir": "src"
  },
  "include": ["src/**/*"]
}

In larger projects with MULTIPLE TypeScript configurations (e.g. one for production code, one for tests with different settings), extends avoids duplicating the SHARED base options.

Bonus: typescript-eslint for additional rules

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

tsc --noEmit (chapter 2) checks TYPE errors. typescript-eslint goes further and additionally checks CODE STYLE rules that are TYPESCRIPT-specific (e.g. "consistently use type for type-only imports", EXACTLY the convention from chapter 24) – often a complementary, not competing, tool alongside tsc itself.