TypeScript Communication & Stakeholder Relations 4 — Questions and Answers
Question 1: A project manager asks how TypeScript's `enum` differs from a plain object of constants, and when each should be used. What is the key distinction to communicate?
- Enums are always faster at runtime than plain objects
- Enums generate runtime JavaScript code and support reverse mapping, while const objects with `as const` are lighter and preferred for tree-shaking (Correct answer)
- Plain objects cannot be used as TypeScript types
- Enums automatically prevent duplicate values at compile time
Correct answer: Enums generate runtime JavaScript code and support reverse mapping, while const objects with `as const` are lighter and preferred for tree-shaking
String enums emit runtime code, while `as const` objects produce no extra output and are fully tree-shakeable, making them preferable in most modern TypeScript projects.
Question 2: A team is debating whether to export internal types from a TypeScript library. What is the recommended stakeholder communication strategy?
- Export all types to give consumers maximum flexibility, with no consideration for future changes
- Export only types that form the stable public API, keeping internal types unexported to preserve the freedom to refactor internals (Correct answer)
- Never export any types from a library
- Export types only if the library has more than ten consumers
Correct answer: Export only types that form the stable public API, keeping internal types unexported to preserve the freedom to refactor internals
Exporting internal types creates implicit contracts with consumers, making internal refactoring a breaking change and increasing maintenance burden.
Question 3: A stakeholder sees a TypeScript error message referencing `Type 'string' is not assignable to type 'never'`. How should you explain what this means?
- The variable was declared with the wrong keyword
- The code has reached a branch TypeScript believes is impossible, or all union members have been excluded, leaving type `never` (Correct answer)
- The string must be converted to a number first
- This error only occurs in JavaScript files, not TypeScript
Correct answer: The code has reached a branch TypeScript believes is impossible, or all union members have been excluded, leaving type `never`
The `never` type represents a value that should never occur; seeing it in an assignment error usually means a conditional narrowed all possibilities away.
Question 4: A developer proposes using `unknown` instead of `any` for externally sourced data. How would you explain the benefit to a non-technical stakeholder?
- `unknown` allows the same operations as `any` but runs faster
- `unknown` forces developers to check and narrow the type before using the value, making unsafe operations visible in code review (Correct answer)
- `unknown` disables type checking for the entire file
- `unknown` is only valid in TypeScript 5.0 and later
Correct answer: `unknown` forces developers to check and narrow the type before using the value, making unsafe operations visible in code review
Unlike `any`, `unknown` requires an explicit type guard or assertion before the value can be used, making dangerous assumptions visible and reviewable.
Question 5: During a retrospective, the team finds that type errors are only discovered late in the CI pipeline. What process change should you recommend?
- Remove TypeScript from the project to speed up development
- Run `tsc --noEmit` as a pre-commit hook or in a fast early CI step so type errors surface before code is merged (Correct answer)
- Only check types in production deployments
- Allow type errors in CI and fix them post-deployment
Correct answer: Run `tsc --noEmit` as a pre-commit hook or in a fast early CI step so type errors surface before code is merged
Adding a type-check step early in the pipeline (or as a pre-commit hook) gives developers immediate feedback and prevents type-broken code from reaching review.
Question 6: A stakeholder asks why some TypeScript projects use `interface` and others use `type` for defining object shapes. What is the key communication point?
- They are always interchangeable with zero distinction
- Interfaces support declaration merging and are preferred for extendable public APIs, while type aliases are more flexible for unions and computed types (Correct answer)
- Type aliases cannot describe object shapes
- Interfaces are deprecated in TypeScript 5.x
Correct answer: Interfaces support declaration merging and are preferred for extendable public APIs, while type aliases are more flexible for unions and computed types
Declaration merging makes interfaces extensible by third-party consumers, while type aliases handle complex scenarios like union types that interfaces cannot express.
Question 7: A new team member is confused about why TypeScript uses structural typing rather than nominal typing. How do you explain this to them?
- TypeScript uses nominal typing where only named types are compatible
- TypeScript uses structural typing, meaning two types are compatible if they have the same shape, regardless of their declared names (Correct answer)
- TypeScript switches between nominal and structural typing based on file extension
- Structural typing only applies to primitive types in TypeScript
Correct answer: TypeScript uses structural typing, meaning two types are compatible if they have the same shape, regardless of their declared names
In TypeScript's structural (duck) type system, any object with the required properties satisfies a type, even if it was declared independently — enabling flexible interoperability.
TypeScript Communication & Stakeholder Relations 4
A project manager asks how TypeScript's `enum` differs from a plain object of constants, and when each should be used.
What is the key distinction to communicate?