TypeScript Risk Assessment & Management 5 — Questions and Answers
Question 1: A TypeScript project uses conditional types extensively. What risk should be managed when conditional types become deeply nested?
- Deeply nested conditional types can hit compiler recursion limits and significantly slow compilation (Correct answer)
- They prevent generic inference from working at all
- They cause runtime stack overflows in Node.js
- They make tree-shaking impossible
Correct answer: Deeply nested conditional types can hit compiler recursion limits and significantly slow compilation
TypeScript's type checker has recursion depth limits, and deeply nested conditional types can exhaust them, causing slow builds or Type instantiation is excessively deep errors.
Question 2: Which risk does 'noUncheckedIndexedAccess' in tsconfig help prevent?
- It adds undefined to the type of array and index-signature access results, forcing developers to handle missing elements (Correct answer)
- It prevents arrays from being indexed at all
- It disables optional chaining on arrays
- It makes all array methods return void
Correct answer: It adds undefined to the type of array and index-signature access results, forcing developers to handle missing elements
Without noUncheckedIndexedAccess, TypeScript assumes indexed access always returns the element type, hiding the real risk that an index may be out of bounds.
Question 3: A function signature uses overloads to handle multiple input types. What risk arises if the implementation signature is too permissive?
- The implementation may accept inputs that no overload covers, creating untested code paths invisible to callers (Correct answer)
- Overloads prevent the function from being called asynchronously
- The compiler will ignore all overload signatures
- It causes module resolution to fail
Correct answer: The implementation may accept inputs that no overload covers, creating untested code paths invisible to callers
The implementation signature must be a superset of all overloads, but if it is overly broad, internal logic may handle edge cases that callers can never produce—creating dead but risky code.
Question 4: What is the risk of using 'namespace' (internal modules) in a modern TypeScript project that also uses ES modules?
- Mixing namespaces and ES module imports can cause confusing compilation output and is unsupported in some bundlers (Correct answer)
- Namespaces prevent any interface from compiling
- Namespaces disable strict mode automatically
- Namespaces cannot contain interfaces or types
Correct answer: Mixing namespaces and ES module imports can cause confusing compilation output and is unsupported in some bundlers
Namespaces are a legacy TypeScript construct; combining them with ES module syntax creates ambiguity in module output and is discouraged in modern codebases.
Question 5: A team plans to upgrade TypeScript from v4 to v5. Which risk management step is most important before upgrading?
- Running the new compiler on the existing codebase and reviewing all new type errors before merging (Correct answer)
- Disabling all strict flags during the upgrade
- Removing all generic constraints to avoid breakage
- Upgrading all @types packages first without changing TypeScript version
Correct answer: Running the new compiler on the existing codebase and reviewing all new type errors before merging
Major TypeScript versions can introduce stricter inference or breaking changes; a trial compilation reveals new errors that must be resolved before the upgrade ships.
Question 6: When using 'satisfies' operator (TypeScript 4.9+), what specific risk does it mitigate compared to a direct type annotation?
- It validates the value against a type without widening the inferred type, preserving narrower literal types for downstream use (Correct answer)
- It prevents the value from being reassigned
- It removes the need for type guards in switch statements
- It makes the value immutable at runtime
Correct answer: It validates the value against a type without widening the inferred type, preserving narrower literal types for downstream use
A direct annotation widens the type to the annotation, losing literal inference; satisfies checks conformance while keeping the narrower inferred type available.
Question 7: Which dependency risk arises when a TypeScript project pins @types packages to a different major version than their corresponding runtime library?
- The type definitions may describe an API that does not match the installed runtime version, causing type-correct code to fail at runtime (Correct answer)
- The project will fail to compile entirely
- Tree-shaking will remove the mismatched types
- The compiler will automatically downgrade to the matching @types version
Correct answer: The type definitions may describe an API that does not match the installed runtime version, causing type-correct code to fail at runtime
If @types/library@3 is installed alongside library@4, the types describe version 3's API, so code that passes type checking may call methods that behave differently or do not exist in version 4.
TypeScript Risk Assessment & Management 5
A TypeScript project uses conditional types extensively.
What risk should be managed when conditional types become deeply nested?