TypeScript Declaration Shape
Flags interface/class/namespace shape problems: empty interfaces, oversized definitions, deep inheritance, declaration merging, and missing return types.
The way TypeScript declarations are shaped affects readability, refactor cost, and how well downstream tooling can leverage the type system. Empty interfaces hide intent, oversized interfaces resist focused changes, deep inheritance trees obscure data flow, and namespaces resist the module-aware tooling that ES modules unlock. This analysis surfaces these shape problems so they can be addressed before they entrench. Inheritance depth is measured within the file only: a class extending a base declared in another module is measured at depth 1, so cross-module hierarchies read shallower than they are; resolving imported bases needs the type checker and belongs to the type-aware lane.
Severity guide
- info
- A declaration shape is unusual but not problematic, so review and refactor when convenient.
- warning
- A declaration shape is hindering readability or refactor cost; the listed item should be addressed.
- critical
- Not currently emitted by this analysis.
Remediation
Replace empty interfaces with type aliases, split oversized interfaces, prefer ES modules over namespaces, and add explicit return types to exported functions.
Replace empty interfaces with type aliases, split oversized interfaces, prefer ES modules over namespaces, and add explicit return types to exported functions.