code-graph: complete dependency detection in TypeScript, Python, and Go

[lsmonki]

Context

While reviewing the code-graph work for dynamic dependencies in PHP, it became clear that there is also relevant debt in the non-PHP adapters.

Today the provider registers default adapters for TypeScript, Python, Go, and PHP, but the actual support level is uneven. In particular:

• TypeScript handles static import ... from ... forms reasonably well and uses them for IMPORTS and CALLS.
• Python covers import ... and from ... import ..., with some relative import resolution and simple call resolution.
• Go parses imports and symbols, but in practice it still does not build useful IMPORTS or CALLS relations.
• Resolution in the indexer still depends on extractImportedNames() + resolveImports() + extractRelations(), so anything that falls outside that model is invisible to the graph.

This makes the code graph acceptable for simple static imports, but incomplete for real dependency detection in modern projects.

Current gaps

TypeScript

• No detection of dynamic import().
• No detection of require('...') in CommonJS/interoperability scenarios.
• Side-effect imports such as import './polyfill' do not enter the ImportDeclaration model, so they do not go through the normal resolution pipeline.
• CALLS extraction resolves simple identifiers, but does not cover member expressions such as obj.method() or ns.fn() well.
• There is no support for tsconfig path aliases (paths, baseUrl) or more complex project layouts.

Python

• No detection of dynamic imports via importlib.import_module() or __import__().
• import x.y is modeled syntactically, but that does not always match the name that is actually accessible in the importing module.
• Package/submodule resolution is still limited for real-world layouts (src/, namespace packages, etc.).
• CALLS resolution is heuristic and name-based; it does not cover instance dispatch, inheritance, mixins, monkey patching, etc. well.

Go

• The adapter parses import statements, but extractRelations() currently emits only DEFINES.
• No real IMPORTS relations are emitted.
• No CALLS relations are emitted for imported functions or methods.
• It still needs to resolve selector_expression (pkg.Func(), obj.Method()), which is the normal case in Go.
• Alias imports, dot imports, and blank imports are not handled well yet.
• Module/package resolution needs to be more precise than the current state based on imported name and prefix matching.

Cross-cutting gap: inheritance and type hierarchy

At some point we also need to address inheritance and type hierarchy explicitly, because that is currently not covered as part of the dependency model.

This applies at least to:

• extends / implements in TypeScript
• class inheritance and method resolution in Python
• promoted methods / receiver-related composition in Go

Even if this eventually becomes a separate issue, it should remain visible here because it directly affects call analysis, navigation, and blast-radius accuracy.

Why this matters

Without these improvements, the code graph:

• under-represents real dependencies
• produces incomplete CALLS data
• reduces the reliability of impact analysis
• can make some repositories look more loosely coupled than they really are

Suggested direction

• Complete Go until it can emit useful IMPORTS and CALLS, not just parse imports.
• Extend TypeScript to cover dynamic import, require(), and side-effect imports.
• Extend Python to cover importlib / __import__ and improve module/package resolution.
• Design an extension to the model or adapters for inheritance/type relations.
• Define explicitly what should count as a “detectable dependency”: safe static only, heuristic dynamic, or both with different confidence levels.

Related context

There is an active PHP-focused change already in progress:

• php-adapter-dynamic-deps

This issue records the equivalent debt in the non-PHP adapters so it can be addressed later, ideally without mixing it into the PHP-specific framework/loader work.

[lsmonki]

Related: constructor injection not detected as dependency

While reviewing the impact analysis for TemplateExpander (a class used in NodeHookRunner), noticed that downstream shows 0 dependents:

$ specd graph impact --symbol TemplateExpander --direction downstream
directDependents: 0
indirectDependents: 0

But TemplateExpander is injected via constructor in NodeHookRunner:

// hook-runner.ts
constructor(expander: TemplateExpander) {
  this._expander = expander
}

This is a specific case of the broader gap mentioned in the issue: the TypeScript adapter only detects call_expression nodes for CALLS, but doesn't track constructor parameter injection or type-based dependencies.

The same applies to any DI pattern where a class receives dependencies via constructor injection — these aren't captured as downstream dependents.

This affects impact analysis accuracy for any code using constructor injection patterns (which is the recommended pattern in this codebase's hexagonal architecture).

Suggested fix: Extend the TypeScript adapter to track type references in constructor parameters as dependencies. This would also help with detecting implements/extends relationships mentioned in the cross-cutting gap section.

[lsmonki]

Additional suggestion: track constructor dependencies

To complement the gaps already listed, we should also track:

1. Constructor calls — new ClassName() expressions should create CALLS relationships
2. Constructor injection — constructor parameter type annotations (e.g., constructor(expander: TemplateExpander)) should create dependencies to those types
3. Type annotations in parameters — not just parameter names, but the type being injected

This is particularly important for hexagonal architectures where DI is the primary pattern. Without this, impact analysis severely under-reports dependencies because most "usage" of a class comes through instantiation and injection, not direct function calls.

Example:

// Currently NOT detected as a dependency
class NodeHookRunner {
  constructor(expander: TemplateExpander) {  // ← should track TemplateExpander
    this._expander = expander
  }
}

// Currently NOT detected as a dependency  
const expander = new TemplateExpander(builtins)  // ← should track TemplateExpander

This would make impact analysis much more accurate for projects using constructor injection patterns.

[lsmonki]

Related to: #54

This issue (#52) and #54 are complementary:

• code-graph: complete dependency detection in TypeScript, Python, and Go #52 documents what gaps exist in dependency detection
• Add a shared scoped binding environment for multi-language call resolution #54 proposes the architecture to fix those gaps (Scoped Binding Environment)

Specifically, the constructor injection problem described above would be addressed by #54's "Scoped Binding Environment" layer that tracks:

• typed parameters in constructors
• explicit new ClassName() constructions
• receiver bindings

These two issues should be addressed together — #54 provides the design, #52 provides the concrete gaps to validate against.