[Bug] dead-code, health, and workspace CLI commands report false-positive unreachable files for TS/JS projects using @/ path aliases

[tingtingdisco]

Describe the Bug

The dead-code, health, and workspace CLI commands rebuild the dependency graph in-memory without wiring up the
TsconfigResolver. As a result, TS/JS path aliases like @/components/Foo don't resolve to their target files
during the rebuild — they become external: nodes, so the real target files get in_degree = 0 and are falsely
flagged as unreachable.

The init pipeline does not have this bug: it runs a dedicated tsconfig phase that calls
graph_builder.set_tsconfig_resolver(...) before build()
(packages/core/src/repowise/core/pipeline/phases/ingestion.py:328-348). The CLI commands don't replicate this
wiring.

Steps to Reproduce

1. In a TS project with @/* → ./src/* path alias in tsconfig.json, have src/routes/layout.tsx import
   Sensor from @/components/SensorProvider.
2. Index the repo: repowise init . --no-workspace --index-only
3. Run: repowise dead-code . --no-workspace --kind unreachable_file --format json

Expected Behavior

src/components/SensorProvider.tsx is not listed as unreachable (it's imported by src/routes/layout.tsx).

Actual Behavior

src/components/SensorProvider.tsx is reported as unreachable_file with "reason": "File has no importers (in_degree=0)", confidence: 0.7, safe_to_delete: true.

On a real 800-file TS project, 171 of 347 unreachable_file findings (49%) were false positives — every file
imported via @/ was misclassified.

The persisted graph in wiki.db is correct: graph_edges contains ('src/routes/layout.tsx', 'src/components/SensorProvider.tsx', 'imports'). The bug is only in the in-memory graph rebuild the CLI performs.

Affected files (all in packages/cli/src/repowise/cli/commands/):

• dead_code_cmd.py (~line 143–156)
• health_cmd.py (~line 189–210)
• workspace_cmd.py (~line 681)

Environment

• OS: macOS 15
• Python version: 3.14.6
• Repowise version: 0.25.0
• Installation method: pipx

Additional Context

Root cause: TsconfigResolver is constructed and attached to GraphBuilder only in the init pipeline. The
resolver is read by resolve_ts_js_import
(packages/core/src/repowise/core/ingestion/resolvers/typescript.py:60-64) during build(). Without it attached,
ctx.tsconfig_resolver is None and non-relative imports fall through to add_external_node(module_path).

Suggested fix: mirror the pipeline's wiring in each CLI command before graph_builder.build(), or extract a shared
wire_tsconfig_resolver(graph_builder, repo_path, include_submodules, include_nested_repos) helper in
repowise.core.ingestion and call it from the pipeline and all three CLI commands.

Related: PR #71 introduced tsconfig alias resolution (pipeline-only); PRs #299 and #244 fixed the same class of
resolver-not-wired false-positive bug for CommonJS require() and Python imports respectively.

[kishansaaai]

Ill work on it

[RaghavChamadiya]

Thanks for the exceptionally detailed report, the diagnosis is correct on all counts:

• dead_code_cmd.py:156, health_cmd.py:204, and workspace_cmd.py:693 all call graph_builder.build() directly with no set_tsconfig_resolver() beforehand.
• The pipeline's tsconfig phase (ingestion.py:328-348) is the only place the resolver gets wired, so any code path that rebuilds the graph in-memory outside the pipeline inherits this bug.

The shared-helper approach is the right call. There's a good precedent for it: dead_code_cmd.py already replicates the pipeline's framework-aware synthetic-edge wiring (the detect_tech_stack block right after build()) to suppress the exact same category of in_degree=0 false positive. That logic is duplicated too, so we're accumulating drift between the pipeline and the CLI commands.

If you're picking this up @kishansaaai, the cleanest shape is:

1. Extract wire_tsconfig_resolver(graph_builder, repo_path, *, include_submodules, include_nested_repos) into repowise.core.ingestion (guard it on the presence of TS/JS parsed files, same as the pipeline does).
2. Call it in the pipeline in place of the inline block, and in all three CLI commands immediately before graph_builder.build().
3. Add a regression test using the repro in the issue: a @/* alias where the aliased target must not appear as unreachable_file. tests/unit/ingestion is the right home.

One thing to watch: the resolver needs the full parsed path set (graph_builder._parsed_files.keys()), so the helper has to run after all add_file() calls, not before.