TypeScript Risk Assessment & Management 2 — Questions and Answers
Question 1: Which TypeScript compiler option helps catch potential null dereference risks at compile time?
- strictNullChecks (Correct answer)
- noImplicitAny
- esModuleInterop
- allowJs
Correct answer: strictNullChecks
strictNullChecks prevents assigning null or undefined to typed variables unless explicitly allowed, catching null dereference risks at compile time.
Question 2: A team inherits a large JavaScript codebase and must assess migration risk. Which TypeScript feature allows incremental adoption with the least disruption?
- allowJs: true with gradual .ts conversion (Correct answer)
- Rewriting all files to .ts before running
- Enabling noImplicitAny immediately on all files
- Using declare module for every JS file
Correct answer: allowJs: true with gradual .ts conversion
allowJs lets TypeScript coexist with JavaScript files, enabling incremental migration without requiring a full rewrite upfront.
Question 3: What risk does the 'any' type introduce in a TypeScript codebase?
- It bypasses type checking, allowing runtime errors to go undetected (Correct answer)
- It causes compilation to fail on all targets
- It prevents using generics in the same file
- It disables tree-shaking in bundlers
Correct answer: It bypasses type checking, allowing runtime errors to go undetected
The any type opts out of TypeScript's type system entirely, meaning type errors that would normally be caught at compile time can become runtime failures.
Question 4: When using third-party libraries without @types definitions, what is the safest risk mitigation strategy?
- Write a custom .d.ts declaration file for the library (Correct answer)
- Import the library with require() instead of import
- Set noImplicitAny to false globally
- Use eval() to call library functions
Correct answer: Write a custom .d.ts declaration file for the library
Writing a custom declaration file provides type safety coverage for untyped libraries without weakening the rest of the project's type settings.
Question 5: Which pattern reduces the risk of a discriminated union being handled incompletely at runtime?
- Adding an exhaustiveness check with a never-typed default branch (Correct answer)
- Using optional chaining on every union member
- Casting to unknown before switching
- Wrapping the switch in a try-catch
Correct answer: Adding an exhaustiveness check with a never-typed default branch
Assigning the default branch to a never variable causes a compile error if a new union member is added but not handled, enforcing completeness.
Question 6: A developer uses 'as' type assertions frequently. What operational risk does this introduce?
- Assertions silence the compiler without guaranteeing the runtime type is correct (Correct answer)
- Assertions make the build output larger
- Assertions prevent interfaces from being extended
- Assertions disable source maps
Correct answer: Assertions silence the compiler without guaranteeing the runtime type is correct
Type assertions tell the compiler to trust the developer's claim about a type, bypassing checks and potentially causing silent runtime failures if the claim is wrong.
Question 7: Which tsconfig setting helps manage the risk of accidentally shipping development-only debug code to production?
- removeComments combined with a production-specific tsconfig that strips debug imports (Correct answer)
- Setting target to ES3 in production
- Enabling declaration in production builds
- Using paths aliases for debug modules
Correct answer: removeComments combined with a production-specific tsconfig that strips debug imports
A separate production tsconfig can exclude debug files and strip comments, reducing the risk of exposing internal logic or performance-heavy debug code.
TypeScript Risk Assessment & Management 2
Which TypeScript compiler option helps catch potential null dereference risks at compile time?