package.json workspaces cross-repo IMPORTS still produce zero edges (v0.7.0 follow-up to #308)

[GonEbal]

Summary

Following the v0.7.0 fix in #308 (tsconfig.json paths), cross-package IMPORTS still produce zero edges for monorepos that use package.json workspaces + Lerna/Yarn workspaces (the most common JS monorepo pattern) instead of tsconfig path aliases.

The README claims this is supported via generic @myorg/pkg manifest resolution in pass_pkgmap.c:

Generic package / module resolution — bare specifiers like @myorg/pkg, github.com/foo/bar, use my_crate::foo resolved via manifest scanning (package.json, go.mod, Cargo.toml, ...)

However, in my testing on v0.7.0 (macOS arm64), pass_pkgmap.c either does not run or silently produces zero entries — no pkgmap.scan_repo / pkgmap.scan / pkgmap.build log lines appear during indexing, and zero cross-package IMPORTS edges are produced.

Environment

• codebase-memory-mcp: 0.7.0 (verified --version)
• OS: macOS 24.6.0 (Darwin arm64)
• Install method: official install.sh (ui variant)

Minimal reproduction

mkdir -p cbm-test/pkg-a/src cbm-test/pkg-b/src

cat > cbm-test/pkg-a/package.json <<EOF
{"name": "@test/pkg-a", "main": "src/index.js"}
EOF
cat > cbm-test/pkg-b/package.json <<EOF
{"name": "@test/pkg-b", "main": "src/index.js"}
EOF

cat > cbm-test/pkg-a/src/index.js <<EOF
import { foo } from '@test/pkg-b';
export const a = () => foo();
EOF
cat > cbm-test/pkg-b/src/index.js <<EOF
export const foo = () => 42;
EOF

codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/cbm-test"}' 2>&1 | grep -iE "pkgmap"
# → no output (expected: pkgmap.scan_repo / pkgmap.build log lines)

codebase-memory-mcp cli query_graph '{"project":"tmp-cbm-test","query":"MATCH (a)-[r:IMPORTS]->(b) RETURN a.file_path, b.file_path"}'
# → 0 rows

Expected: an IMPORTS edge from pkg-a/src/index.js to pkg-b/src/index.js because the pkgmap should resolve @test/pkg-b via the package.json "name" field.

Actual: 0 IMPORTS edges, no pkgmap log lines.

Real-world impact

I'm indexing a 13-repo monorepo workspace (~140K nodes, ~214K edges, 13K files). All repos are Lerna+Yarn workspaces publishing internal packages under @pandora/ / @commerce-exp/. Cross-repo imports use the published package name. Expected behavior: graph treats them as a single fleet with normal IMPORTS edges. Actual: every cross-repo import is dropped.

Workaround attempted: synthesize a root tsconfig.json at the workspace level with paths mapping every internal @pandora/foo → <repo>/packages/foo/src/index.ts. This did trigger path_alias.c (saw path_alias.files.cap_hit kept=256_of_more warn) but still produced zero cross-repo edges because:

1. CBM_PATH_ALIAS_MAX_ENTRIES = 256 per single tsconfig (we have 328+ packages → 70+ silently dropped)
2. CBM_PATH_ALIAS_MAX_FILES = 256 total tsconfigs per repo walk (we have 352 → root tsconfig may not be among the 256 selected)
3. cbm_path_alias_find_for_file picks the nearest ancestor scope, so every source file inside an inner package picks up its own local tsconfig.json rather than the workspace-root one we wrote, never seeing our cross-repo paths

Suggested improvements

1. Diagnose pass_pkgmap.c silent failure on JS/TS workspaces (no log emission at all suggests it isn't being invoked or returns NULL before logging). The walker logic in pkgmap_walk_dir looks correct from the source. Add an info log even when 0 entries are produced.
2. Honor package.json workspaces arrays so a root manifest with "workspaces": ["packages/*"] (or globs across child repos) gives a scope to bare-specifier resolution that spans them.
3. Aggregate tsconfig path aliases from ancestors rather than nearest-only — or, when a file matches no nearer alias, fall back to ancestors instead of stopping at the first tsconfig found.
4. Raise (or make configurable) the CBM_PATH_ALIAS_MAX_ENTRIES = 256 and CBM_PATH_ALIAS_MAX_FILES = 256 caps. Real monorepos easily exceed both.
5. Document the limitation in the README under "Cross-repo intelligence" — specifically that @myorg/pkg resolution currently does not bridge across package.json-workspaces sibling repos, even though the README example "@myorg/pkg" implies it does.

Happy to test fixes against a public 13-repo repro if helpful.

[DeusData]

Update: I dug into this and found + fixed one real gap — the repo-wide manifest walk (cbm_pkgmap_scan_repo) was a no-op on Windows, so package.json workspace names were never resolved there (cross-package IMPORTS = 0). It's now cross-platform and depth-bounded (cannot hang on directory junctions) on main (586729b), with a regression test.

That said, I want to be careful: on macOS/Linux I can't reproduce zero cross-package edges with a standard workspaces layout — a fixture where packages/b imports a sibling by its name (@org/a) resolves to a cross-package IMPORTS edge for me (now covered by contract_edge_workspaces_imports_issue408). Since your report was on macOS, your specific layout may be hitting a different path.

Could you share a minimal repro? Specifically:

• the root package.json and a couple of package package.json files (do the packages set "name"? "main" or "exports"?),
• one example cross-package import statement,
• and whether any pkgmap.scan_repo / pkgmap.build lines appear in the logs (now visible with CBM_LOG_LEVEL=debug).

Leaving this open pending that — happy to chase the macOS case once I can reproduce it.