Unexpected behaviour with Typescript class/method dependents

[mcky]

I'm trying to integrate sem into my workflow but we heavily use dependency-injection in our app and it led me to notice some confusing behaviour around class method dependencies.

It may be that my mental model of sem/the graph is just wrong - initially I thought sem didn't flag dependents at all as they were never showing, but after creating some more simple repro cases that turned out to be wrong

Apologies in advance if language-specific things like this are out of scope (e.g. it's a tree-sitter thing) or this is intended behaviour

Example 1: Instantiating a class directly

class Foo {
    doFoo() {}
}

class Bar {
    foo = new Foo()
    doBar() {
        this.foo.doFoo()
    }
}

Checking impact on Foo works as expected - it flags Bar.doBar as a dependent

> sem impact Foo
⊕ class Foo (sem_test.ts:1–5)

  ← depended on by:
    ← class Bar (sem_test.ts)
    ← field foo (sem_test.ts)

  ! 3 entities transitively affected (depth 2):

    Direct dependents (2)
      → class Bar (sem_test.ts:L7)
      → field foo (sem_test.ts:L8)

    Depth 2 (1)
      → method doBar (sem_test.ts:L10)

But checking Foo.doFoo itself shows nothing. If I'm dealing with large classes
used in many places throughout the app, being able to identify the knock-on effect
of a single method would be a great way of saving tokens

> sem impact Foo.doFoo
⊕ method doFoo (sem_test.ts:2–4)

  ✓ No other entities are affected by changes to this entity.

Checking the inverse dependencies of Bar / Bar.doBar doesn't flag Foo.doFoo

> sem impact Bar
⊕ class Bar (apps/api/app/services/sem_test.ts:5–11)

  → depends on:
    → class Foo (apps/api/app/services/sem_test.ts)

  ✓ No other entities are affected by changes to this entity.

> sem impact Bar.doBar
⊕ method doBar (apps/api/app/services/sem_test.ts:8–10)

  → depends on:
    → field foo (apps/api/app/services/sem_test.ts)

  ✓ No other entities are affected by changes to this entity.

Example 2: Class instantiated via DI

Assuming the following private foo was resolved by a DI container:

class Foo {
    doFoo() {}
}

class Bar {
    constructor(private foo: Foo) {}
    doBar() {
        this.foo.doFoo()
    }
}

In the first example it flagged doBar at depth 2, but here it only identifies
the constructor as a dependent

> sem impact Foo
⊕ class Foo (sem_test.ts:1–3)

  ← depended on by:
    ← method constructor (sem_test.ts)

  ! 1 entities transitively affected (depth 2):

    Direct dependents (1)
      → method constructor (sem_test.ts:L6)

And when checking the doFoo method it again flags no dependents

> sem impact Foo.doFoo
⊕ method doFoo (sem_test.ts:2–2)

  ✓ No other entities are affected by changes to this entity.

Checks on Bar / Bar.doBar also flag up no dependencies

> sem impact Bar
⊕ class Bar (apps/api/app/services/sem_test.ts:5–11)

  ✓ No other entities are affected by changes to this entity.

> sem impact Bar.doBar
⊕ method doBar (apps/api/app/services/sem_test.ts:8–10)

  ✓ No other entities are affected by changes to this entity.

[rs545837]

I will get back here soon.