On v0.12.2 and current main, declarations that change which version of a dependency gets installed are dropped. Using Go 1.27.1:
r, _ := manifests.Parse("package.json", []byte(`{"name":"app","version":"1.0.0","dependencies":{"express":"^4.18.2"},"overrides":{"semver":"7.5.4"},"resolutions":{"minimist":"1.2.8"}}`))
fmt.Printf("%+v\n", r)
// Dependencies:[{Name:express Version:^4.18.2 ...}] overrides and resolutions absent
r2, _ := manifests.Parse("Cargo.toml", []byte("[package]\nname = \"app\"\nversion = \"0.1.0\"\n\n[dependencies]\nserde = \"1.0\"\n\n[patch.crates-io]\nserde = { git = \"https://github.com/serde-rs/serde\", branch = \"fix\" }\n"))
fmt.Printf("%+v\n", r2)
// Dependencies:[{Name:serde Version:1.0 PURL:pkg:cargo/serde ...}] the patch is absentIn the second case the reported dependency is wrong about what a build would use: serde resolves from a git branch, not from crates.io. The Go parser already accounts for this, where collectReplacedModules reads replace directives before collecting requirements, so the same class of declaration is handled in one ecosystem and silently discarded in the others.
Formats worth covering:
- npm
overrides and Yarn resolutions in package.json
- pnpm
overrides and patchedDependencies, which live in pnpm-workspace.yaml under pnpm 10 and under the pnpm key in package.json in earlier versions
- Cargo
[patch.*] and [replace] in Cargo.toml
I would keep these out of Dependencies and record them separately, the way Declarations already preserves source-level references without merging them into the effective model. An entry needs the target package, the replacement (version, path, git source or patch file), and its location in the source file, so a caller can report that an override exists without the library deciding how the package manager would apply it.
Public Parse tests should cover each format with fixtures, including an override naming a package that is not otherwise a dependency, and a patch file reference that points outside the manifest directory.
On v0.12.2 and current main, declarations that change which version of a dependency gets installed are dropped. Using Go 1.27.1:
In the second case the reported dependency is wrong about what a build would use:
serderesolves from a git branch, not from crates.io. The Go parser already accounts for this, wherecollectReplacedModulesreadsreplacedirectives before collecting requirements, so the same class of declaration is handled in one ecosystem and silently discarded in the others.Formats worth covering:
overridesand Yarnresolutionsinpackage.jsonoverridesandpatchedDependencies, which live inpnpm-workspace.yamlunder pnpm 10 and under thepnpmkey inpackage.jsonin earlier versions[patch.*]and[replace]inCargo.tomlI would keep these out of
Dependenciesand record them separately, the wayDeclarationsalready preserves source-level references without merging them into the effective model. An entry needs the target package, the replacement (version, path, git source or patch file), and its location in the source file, so a caller can report that an override exists without the library deciding how the package manager would apply it.Public
Parsetests should cover each format with fixtures, including an override naming a package that is not otherwise a dependency, and a patch file reference that points outside the manifest directory.