Skip to content

feat(modgraph): read the tool directives of the main go.mod - #57

Merged
abhisek merged 2 commits into
mainfrom
claude/modgraph-tool-directives
Oct 26, 2026
Merged

abhisek merged 2 commits into
mainfrom
claude/modgraph-tool-directives

Conversation

@abhisek

@abhisek abhisek commented Oct 24, 2026 •

Copy link
Copy Markdown
Member

What was wrong

Build parsed the main go.mod with modfile.ParseLax, and ParseLax drops the tool lines. So the graph had no edge to the module of a tool. vet read such a module as unused. But go tool builds and runs the code of the tool with the build list of the module.

What this changes

  • Build parses the main go.mod with modfile.Parse, as the go command does. Discover and readWorkspace already parse the same file strictly, so the Discover and Build path fails on no new input. A caller that passes its own sources gets an error only for a go.mod that the go command rejects too.
  • Build links each tool package as an import of the main module, with go.mod and the line as the evidence. A tool edge is not test-only.
  • A tool that no module of the build list holds makes the main module open.
  • Version is 2, because the same input gives another graph.
  • Docs: the walk, the oracle test, and a note on workspaces. The graph of a workspace module holds only the tools of its own go.mod.

Tests

  • TestBuildReadsTheToolsOfTheMainModule: a tool of a dependency, a tool in a testdata directory of the main module, and a tool that no module holds. A test file also imports the tool, and the edge stays non-test.
  • TestBuildRejectsABadInput: a directive that the go command rejects.
  • TestBuildReachesTheModulesOfATool serves a tool module from a proxy on the disk and checks the graph against go list.
  • The oracle test lists the tools of go.mod in a second go list -deps call with no -test. On this repository it now covers the lefthook tool.
  • Each new test fails on main.

A Fable sub-agent reviewed the change. It found an oracle that was too strict for a tool with test files, a test case that passed without the fix, and a gap in the workspace docs. The second commit fixes them.

Part of FOU-589. safedep/vet pins this after the merge.


Generated by Claude Code

Summary by CodeRabbit

  • New Features

    • Dependency graphs now include modules referenced by tool directives in the main module’s go.mod, along with their imported dependencies.
    • Workspace guidance clarifies that each module’s graph includes its own tools, and that every workspace module’s graph must be checked before concluding a module is unused.
  • Bug Fixes

    • Invalid main-module go.mod files now produce an error when they would be rejected by the Go command.
  • Documentation

    • Oracle-test guidance now includes repository tools among the inputs checked across four platforms.

Build parsed the main go.mod with ParseLax, and ParseLax drops the tool
lines. So the graph had no edge to the module of a tool. vet then read
such a module as unused, but go tool builds and runs its code with the
build list of the module.

Build now parses the main go.mod as the go command does. It links each
tool package as an import of the main module from go.mod. A tool that no
module holds makes the main module open. Version is 2, because the same
input gives another graph.

The oracle test adds the tools of the go.mod to go list -deps. A
synthetic test serves a tool module from a proxy on the disk and checks
the graph against go list.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm
Signed-off-by: Claude <noreply@anthropic.com>
The oracle test named the tools of go.mod in the go list -deps -test
call. -test applies to each named package, so go list gave the test
imports of a tool of a dependency. The graph never reads the test files
of a dependency, so the oracle could fail on an edge that no build has.
The test now lists the tools in a second go list call with no -test.

The case for a tool of the main module passed without the fix. It now
names a package in testdata, which the walk of the main module skips. A
test file of the main module also imports the tool, and the tool edge
must not be test-only. A go.mod with a directive that the go command
rejects is now an error, and a case pins it.

The docs say that the graph of a workspace module holds only the tools
of its own go.mod.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm
Signed-off-by: Claude <noreply@anthropic.com>
@safedep

safedep Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

SafeDep Report Summary

Green Malicious Packages Badge Green Vulnerable Packages Badge Green Risky License Badge

No dependency changes detected. Nothing to scan.

View complete scan results →

This report is generated by SafeDep GitHub App

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-24T13:29:29.449153Z 360855d PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@coderabbitai

coderabbitai Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review.

Recent review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: QUIET
  • Plan: Advanced
  • Run ID: 886ba74e-5f83-481f-b2d9-0647099f5ad5
Commits

Reviewing files that changed from the base of the PR and between c270ee9 and 360855d.

Files selected for processing: 5
  • docs/modgraph.md
  • modgraph/buildlist_test.go
  • modgraph/graph.go
  • modgraph/graph_test.go
  • modgraph/oracle_test.go

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

The graph builder now parses the main go.mod strictly and adds its tool directives to the module graph. The graph version changes to 2. Tests and documentation cover tool graph edges, workspace behavior, and comparisons with go list.

Changes: Tool directives in module graphs

Layer / File(s) Summary
Parse go.mod and link tool imports
modgraph/graph.go, docs/modgraph.md
Build uses strict parsing, records main-module tool directives as imports with go.mod evidence, and links them from the main module. The graph version changes to 2. The documentation describes tool directives and workspace graph scope.
Check tool graph behavior
modgraph/graph_test.go, modgraph/buildlist_test.go, modgraph/oracle_test.go
Tests cover resolved and unresolved tools, graph edges, invalid go.mod input, and comparisons with go list. The oracle helper reads test and tool dependencies.

Priority: Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant Build
  participant modfile.Parse
  participant builder.run
  participant PackageQueue
  Build->>modfile.Parse: Parse the main go.mod
  Build->>builder.run: Run graph construction with tool imports
  builder.run->>PackageQueue: Link tool imports, then drain queued packages
Loading

Possibly related PRs

  • safedep/code#56: Adds workspace build-list discovery; this PR describes how each workspace module graph handles its own tool directives.
  • safedep/code#54: Introduces Build and the graph model that this PR updates to include tool-module edges.
Merge Risk: Minimal · up to 36085

The tool-graph change is ready to merge after normal checks.

Pre-merge checks: Passed 4 · Failed 1

Failed Failed checks: 1 warning

Check name Status Explanation Resolution
Docstring Coverage Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 4 files. (1 skipped: … Write docstrings for the functions missing them to satisfy the coverage threshold.
Passed Passed checks: 4 passed
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely describes the main change: reading tool directives from the main go.mod file.
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage

Explanation

Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 4 files. (1 skipped: 1 unsupported.)

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

Finishing Touches: 💡 1
📝 Generate docstrings: 💡
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.26%. Comparing base (c270ee9) to head (360855d).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #57      +/-   ##
==========================================
+ Coverage   77.23%   77.26%   +0.02%     
==========================================
  Files         174      174              
  Lines       17129    17140      +11     
==========================================
+ Hits        13230    13243      +13     
+ Misses       3115     3114       -1     
+ Partials      784      783       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@abhisek
abhisek merged commit abcec0a into main Oct 26, 2026
9 checks passed
@abhisek
abhisek deleted the claude/modgraph-tool-directives branch October 26, 2026 16:29
abhisek pushed a commit to safedep/vet that referenced this pull request Oct 26, 2026
safedep/code#57 merged, so the pin moves from the head of its branch to
the merge commit on main. The code is the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm
abhisek added a commit to safedep/vet that referenced this pull request Oct 27, 2026
…ly roots (#844)

* [FOU-589] Start the not-called check at the dependencies of the package

Take a project whose code imports p, where p imports q and q calls the
vulnerable function of p. vet reads no code of q, because the code does
not import q. So the call search finds no path, and the check for
another package that can call p started only at the imported packages.
It found none and the finding read not-called.

The check now also starts at the dependencies of p. A path from one of
them back to p gives transitive. A path through an open package gives
no-dependency-source.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

* [FOU-589] Take the test-only label of a Go root from its go.mod

The module graph of a go.mod roots at the modules that its code imports.
The reach rules took the test-only label of a root from the code usage,
which covers the whole target. So a module that only the tests of one
go.mod import read as a production import when the code of another
go.mod imported it. The label of each path from that root was wrong too.

modgraph marks an edge from the main module that only test files give.
The conversion now marks a root that no other edge of the main module
leads to as a test root. A local module that only tests import passes on
test roots. The reach rules read the label of a root of a graph of
imports from the graph. The scan file keeps the test roots in a new
table, so the scan format is 5. codeusage.Version is 13.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

* [FOU-589] Count a tool directive of go.mod as an import

modgraph read no tool lines of go.mod, so a module that only a tool
directive names read unused. But go tool builds and runs the code of the
tool with the build list of the module.

safedep/code#57 links each tool package as an import of the main module.
This pins safedep/code to the head of that branch. The acceptance script
gives a go.mod whose only use of a module is a tool directive, and the
module that the tool imports is imported through it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

* [FOU-589] Keep an open Go package from not-called, and a built test root from test-only

A Fable review found two gaps in the functions that this branch changes.

An open package can import a module that has no edge in the graph, and
that module can call the package. The search for another caller started
at the edges only, so an open package with source and no call path read
not-called. An open package now gives no-dependency-source.

A module that only test files import directly can also sit below a
non-test root. The build then links it, but its finding read test-only.
A test root now counts as test-only only when no path from a non-test
root reaches it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

* [FOU-589] Take the test-only label of a Go package below a root from its path

CodeRabbit found that a package below a root took the label from the
code usage of the whole target. Take a go.mod whose code reaches a
package only through a module that its tests import. When the code of
another go.mod imports the package, the code usage marks it as a
non-test import, so the finding of the first go.mod read not
test-only.

A package below a root of a graph of imports now takes the label of
the path from the imported packages. The code usage gives the label
only when the graph has no path.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

* [FOU-589] Pin safedep/code to the merge of safedep/code#57

safedep/code#57 merged, so the pin moves from the head of its branch to
the merge commit on main. The code is the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PFQbqPqd9xn1fT6hBsyoUm

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants