Hi! I've been building jest-graph-tia, an open-source Test Impact Analysis orchestrator for Jest that uses graphify's knowledge graph as its semantic layer, and I'd love to become a contributor to graphify.
What it does: on a PR it takes git diff → expands the changed-file set through graphify-out/graph.json (reverse-BFS with per-confidence-tier hop budgets: EXTRACTED 6 / INFERRED 2 / AMBIGUOUS off) → hands the expanded set to jest --findRelatedTests. The graph only ever widens Jest's input, so selection can never be less safe than Jest's own.
Real results (production Next.js repo, 23,403 nodes / 47,913 edges): on 5 of 10 recent commits, graph expansion selected 5–8 genuinely affected tests that Jest's own scanner missed — root cause verified as import type dependencies, which Jest's dependency extractor drops but graphify's tree-sitter pass keeps as EXTRACTED edges. Selection stayed at ~2% of the suite. Also built an audit command (forward-BFS from every test) that found 834 unreachable source files, including a test that imports the wrong module — coverage follows imports, not filenames.
Things I verified against graphify 0.8.39 you may find useful:
node-link schema notes: edges under links, direction = source-depends-on-target — documented in my repo's SPEC after testing on real artifacts
INFERRED edges survive graphify update re-extraction (important for my use case — thank you for that behavior)
incremental update on 23k nodes: ~41s
Where I'd like to contribute: a TIA/CI use-case doc or example, test-selection-oriented edge cases for the JS/TS extractor (type-only imports, re-export barrels, dynamic import() literals), and whatever issues you'd point a new contributor at. If useful, I can also open a PR adding jest-graph-tia to any "built with graphify" list.
Thanks for graphify — the confidence tiers on edges are exactly what makes safe test selection possible.
Hi! I've been building jest-graph-tia, an open-source Test Impact Analysis orchestrator for Jest that uses graphify's knowledge graph as its semantic layer, and I'd love to become a contributor to graphify.
What it does: on a PR it takes git diff → expands the changed-file set through graphify-out/graph.json (reverse-BFS with per-confidence-tier hop budgets: EXTRACTED 6 / INFERRED 2 / AMBIGUOUS off) → hands the expanded set to jest --findRelatedTests. The graph only ever widens Jest's input, so selection can never be less safe than Jest's own.
Real results (production Next.js repo, 23,403 nodes / 47,913 edges): on 5 of 10 recent commits, graph expansion selected 5–8 genuinely affected tests that Jest's own scanner missed — root cause verified as import type dependencies, which Jest's dependency extractor drops but graphify's tree-sitter pass keeps as EXTRACTED edges. Selection stayed at ~2% of the suite. Also built an audit command (forward-BFS from every test) that found 834 unreachable source files, including a test that imports the wrong module — coverage follows imports, not filenames.
Things I verified against graphify 0.8.39 you may find useful:
node-link schema notes: edges under links, direction = source-depends-on-target — documented in my repo's SPEC after testing on real artifacts
INFERRED edges survive graphify update re-extraction (important for my use case — thank you for that behavior)
incremental update on 23k nodes: ~41s
Where I'd like to contribute: a TIA/CI use-case doc or example, test-selection-oriented edge cases for the JS/TS extractor (type-only imports, re-export barrels, dynamic import() literals), and whatever issues you'd point a new contributor at. If useful, I can also open a PR adding jest-graph-tia to any "built with graphify" list.
Thanks for graphify — the confidence tiers on edges are exactly what makes safe test selection possible.