The impact graph knows three kinds of project:
const PROJECTS: &[(&str, ProjectKind, &[&str])] = &[
("cargo.toml", ProjectKind::Cargo, &["target"]),
("package.json", ProjectKind::Npm, &["node_modules"]),
("pyproject.toml", ProjectKind::Python, &[".venv", "venv"]),
];
Which means a Go, Java, Ruby or PHP project's build output looks
abandoned to Diskern even when the project is live — it gets the same
verdict as a directory nobody has touched in two years, which is exactly
the distinction the graph exists to make.
Candidates, each a line in that table plus a store name:
| Marker |
Store |
go.mod |
vendor |
pom.xml |
target |
build.gradle, build.gradle.kts |
build, .gradle |
Gemfile |
vendor/bundle |
composer.json |
vendor |
pubspec.yaml |
.dart_tool, build |
Note target and vendor are shared between ecosystems, which is fine —
STORE_NAMES is a flat list and the marker decides who references what.
Worth checking as you add each one: graph.rs has tests using synthetic
paths, so a new kind needs no filesystem, just a from_entries case
asserting the store comes back referenced.
crates/diskern-core/src/graph.rs:24
The impact graph knows three kinds of project:
Which means a Go, Java, Ruby or PHP project's build output looks
abandoned to Diskern even when the project is live — it gets the same
verdict as a directory nobody has touched in two years, which is exactly
the distinction the graph exists to make.
Candidates, each a line in that table plus a store name:
go.modvendorpom.xmltargetbuild.gradle,build.gradle.ktsbuild,.gradleGemfilevendor/bundlecomposer.jsonvendorpubspec.yaml.dart_tool,buildNote
targetandvendorare shared between ecosystems, which is fine —STORE_NAMESis a flat list and the marker decides who references what.Worth checking as you add each one:
graph.rshas tests using syntheticpaths, so a new kind needs no filesystem, just a
from_entriescaseasserting the store comes back referenced.
crates/diskern-core/src/graph.rs:24