Repository: TypeScript
Issue: Inspect interface composition hierarchy and its full set of members
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

interface extends hierarchy, interface extends tree, interface tree

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

<!-- A summary of what you'd like to see added or changed -->
Inspired by the recently introduced function call tree, I would like to propose a similar kind of feature allowing for easy inspection of an `interface`'s hierarchical composition of other interfaces.

## Use Cases

Interfaces are great for dependency inversion and its `extends` allows for interface segregation. This proposed inspection feature would add the kind of super fluffy developer experience that encourages both principles to be used more liberally.

Currently, when the segregated interfaces are finally composed at some kind of top level and one needs to provide all required functionalities, one would need to keep checking what members are still missing. If a member turns up by surprise, it would take _recursive_ Ctrl+click through _all_ subjects of `extends` to see where that unexpected member is required. This alone is off-putting when one deals with a complex project and would like to keep unit dependencies as small as possible.

With this proposed inspector, one would be able write a unit module, quoting its dependent interfaces without needing to worry that the final composition way up would be hard to trace. There would be very little temptation/excuse to define some kind of God-interface, whose only one or two members are used by any module at a time.

(FWIW in my projects I'm already pursuing dependency inversion in full force and it pays great maintainability dividends. Even with the recursive click-through it is still significantly easier to reason with IMO than God interfaces.)


<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

<!-- Show how this would be used and what the behavior would be -->

For instance, for something like this (in reality, these interfaces would likely live in different files):

```ts
interface A { /* ... */ }
interface B { /* ... */ }
interface C extends A { /* ... */ }
interface D extends B { /* ... */ }
interface E extends C, D { /* ... */ }
```

would give rise to this tree upon inspecting `E`:

```
E
+- C
|  +- A
+- D
|  +- B
+- A
+- B
```

plus a view that shows all effective members of `E`. 

I'm not sure how the listing of members would work precisely, but for starters it would be good to be able to use it to answer questions like:
1. What methods do I now expect to provide?
2. Why do I have to implement method `X`? (For those familiar with Yarn, it would be like `yarn why` on an interface member.) 

I'm sure others can come up with more suggestions on the desirable dev-experience around the core idea.

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).