An analysis of how twenty package managers (Ruby, JavaScript, Rust, Python, C/C++) share or reuse code with each other. Key findings: Pixi depends on 28 uv crates, pnpm depends on 5 Yarn Berry packages, and uv takes cargo-util from Cargo. Eight npm-org packages are shared across npm, Yarn Berry, and pnpm. PyPA's packaging and pyproject-hooks libraries are shared by pip, Poetry, and Conda. pip, Bundler, and Homebrew vendor dependencies rather than declaring them. The analysis connects code sharing (or lack thereof) to security outcomes: shared libraries like npm's tar package meant five path-traversal CVEs in 2021 were fixed once and propagated via version bumps, while independently reimplemented operations like git subprocess wrappers led to the same argument-injection CVE being discovered and fixed separately across six tools over five years.
Questions this post answers
Does pnpm depend on any Yarn Berry packages internally?
pnpm depends on five Yarn Berry packages: @yarnpkg/core, @yarnpkg/lockfile, @yarnpkg/pnp, @yarnpkg/nm, and @yarnpkg/extensions. This is a direct declared dependency, not vendoring. Developers tracking JavaScript package manager internals find dependency relationships like these covered on daily.dev.
How does Pixi relate to uv under the hood?
Pixi declares 28 uv crates as its PyPI backend, including uv-resolver, uv-distribution, uv-client, uv-install-wheel, uv-pep440, and uv-git. This makes Pixi a direct consumer of uv's internal Rust crates rather than a reimplementation. Teams choosing between Pixi and uv for Python environment management can follow the ecosystem on daily.dev.
Why did the same git argument-injection vulnerability keep appearing in different package managers independently?
Each package manager implements its own git subprocess wrapper with no shared library or spec owner, so vulnerabilities are discovered and patched tool by tool. The --end-of-options argument-injection pattern was fixed in Bundler (2021), Composer (2021, 2022), CocoaPods and Poetry (2022), pip (2023), and Go (2026) — each independently, leaving Go exposed for five years after the pattern was first publicly documented. Supply chain security issues like repeated CVE patterns across package managers are tracked on daily.dev.