[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.
Kind: refactor (mechanical, no behavior change). Source: review 6.4, 7.3; register C20, child 1 of the purl tracking issue.
Problem (verified on 045d7ec)
Ecosystem::from_purl is the one map from purl type to ecosystem. Production code outside it still spells the type prefixes inline: 24 starts_with("pkg:<type>/") checks.
- core:
hosted/engine.rs (6, L1382-L1446);
hosted/memory/stages.rs (2);
patch/apply.rs:745 and patch/rollback.rs:355, the npm sidecar gates;
api/client.rs:1338;
vex/verify.rs:210.
- CLI:
commands/vendor.rs (3, L1907-L1943);
commands/bun_preflight.rs (3);
vlt_preflight.rs:50, rollback.rs:2446, get.rs:1536, apply.rs:2315, scan/discovery.rs:108 and scan/hosted/python.rs:28.
All 24 agree with from_purl today (all are case-sensitive prefix tests), so there is no drift yet. But the type vocabulary has 25 copies. A purl-type change, such as accepting pkg:PyPI/, or jsr mapping to Deno, would have to find all of them. And matching on Ecosystem makes the npm-only gates exhaustive and greppable.
Proposed change
- Replace each check with
Ecosystem::from_purl(p) == Some(Ecosystem::X), or a matches! on it. Where a site checks several types, add a small Ecosystem::is_one_of-style helper only if it reads better.
- Delete the inline literals.
- Leave
from_purl itself and the parsers in utils/purl.rs unchanged.
Size and scope
- About 24 one-line production edits across 14 files; no test changes expected.
- Out of scope: the purl builders (later children of the tracking issue), and the
starts_with("pkg:") "is this a purl" tests (utils::purl::is_purl).
Acceptance criteria
Dependencies
[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.
Kind: refactor (mechanical, no behavior change). Source: review 6.4, 7.3; register C20, child 1 of the purl tracking issue.
Problem (verified on
045d7ec)Ecosystem::from_purlis the one map from purl type to ecosystem. Production code outside it still spells the type prefixes inline: 24starts_with("pkg:<type>/")checks.hosted/engine.rs(6, L1382-L1446);hosted/memory/stages.rs(2);patch/apply.rs:745andpatch/rollback.rs:355, the npm sidecar gates;api/client.rs:1338;vex/verify.rs:210.commands/vendor.rs(3, L1907-L1943);commands/bun_preflight.rs(3);vlt_preflight.rs:50,rollback.rs:2446,get.rs:1536,apply.rs:2315,scan/discovery.rs:108andscan/hosted/python.rs:28.All 24 agree with
from_purltoday (all are case-sensitive prefix tests), so there is no drift yet. But the type vocabulary has 25 copies. A purl-type change, such as acceptingpkg:PyPI/, orjsrmapping to Deno, would have to find all of them. Andmatching onEcosystemmakes the npm-only gates exhaustive and greppable.Proposed change
Ecosystem::from_purl(p) == Some(Ecosystem::X), or amatches!on it. Where a site checks several types, add a smallEcosystem::is_one_of-style helper only if it reads better.from_purlitself and the parsers inutils/purl.rsunchanged.Size and scope
starts_with("pkg:")"is this a purl" tests (utils::purl::is_purl).Acceptance criteria
starts_with("pkg:<type>/")remains in non-test code outsidecrawlers/types.rsandutils/purl.rs. Add a source-scan architecture test likecrawlers::architecture_tests, normalizing CRLF.cargo test -p socket-patch-core --libandcargo test -p socket-patch-clistay green; clippy stays clean.Dependencies
hosted/engine.rsandpatch/apply.rshave open PRs (Full Gradle support in agent, hosted and vendored modes #646, sbt, Mill and scala-cli support in agent, hosted and vendored modes #690); the hunks are one line each.