Homebrew vs Bun (package manager)

Headless installs

1. ai-native userHave an agent install and update project dependencies non-interactively, with clear exit codes and errors when something fails

   weight 3 · round drawn
   Homebrew~partialcommunity6/10

   Homebrew documents a clear non-interactive workflow (Brewfile + `brew bundle install`/`check`, plus `NONINTERACTIVE=1` for installs) that an agent could script to install/update project dependencies, and `brew bundle check` provides a scriptable readiness check. However, there is no explicit documentation of exit-code semantics or structured error output for bundle/upgrade failures, and community reports describe unpredictable side effects (e.g. `brew upgrade` unexpectedly upgrading unrelated casks/packages, no reliable rollback) that could confuse automated, non-interactive agent workflows expecting deterministic success/failure signals. missing for 10: documented exit-code/error-schema guarantees for bundle/install/upgrade commands, and evidence that upgrade behavior is deterministic enough for unattended agent use.

   • [claimed-docs] “Adding a `Brewfile` to a project’s repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [claimed-docs] “The Brewfile's dependencies are satisfied.”
   • [claimed-docs] “prepend `NONINTERACTIVE=1` to the installation command”
   • [community] “User reports that 'brew upgrade' started updating ALL casks, even ones marked 'auto_updates: true' in the Cask JSON API, calling it new defa…”
   • [community] “User asks: "Does homebrew still do that insane thing when you want to upgrade a single package it tells you 'hold my beer' and starts instal…”
   • [community] “User requests a better rollback mechanism, having broken their home server multiple times with bad InfluxDB/Grafana updates via Homebrew; no…”

   proof ↗⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun install is scriptable and non-interactive by default (no prompts documented), supports --frozen-lockfile for reproducible CI installs, and errors out when a required dependency isn't cached (bun-docs-5, bun-docs-20, bun-docs-35). However, docs never explicitly discuss exit-code semantics or structured error output for agent consumption, and community reports note install crashes/bugs under certain conditions (bun-comm-7), suggesting real-world reliability caveats. missing for 10: explicit exit-code documentation, structured/parseable error output, independent verification that failures are cleanly reported rather than crashing.

   • [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
   • [claimed-docs] “a required dependency that is not cached is an error”
   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “To install in production mode (without `devDependencies`):”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”

   proof ↗⚑ flag

Manifest editing

1. ai-native userAdd, remove, and upgrade dependencies through CLI commands that safely rewrite the manifest and lockfile, so an agent never hand-edits them

   weight 2 · round to Bun (package manager)
   Homebrew~partialcommunity5/10

   Homebrew's CLI (`brew install`/`uninstall`/`upgrade`) mutates installed-package state, and `brew bundle dump`/`brew bundle install`/`brew bundle check` let a Brewfile (manifest) be generated, synced, and verified without hand-editing — docs explicitly compare it to package.json/Gemfile management. However, there is no true lockfile concept (Brewfile mixes manifest+state) and community reports (comm-1, comm-11) describe upgrade commands unpredictably touching unrelated packages, which undercuts the 'safely and predictably rewrites' framing an agent would need. Missing for 10: an explicit lockfile artifact distinct from the manifest, and evidence of deterministic/idempotent CLI-only dependency edits without unexpected side effects.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “Adding a `Brewfile` to a project’s repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [community] “User reports that 'brew upgrade' started updating ALL casks, even ones marked 'auto_updates: true' in the Cask JSON API, calling it new defa…”
   • [community] “User asks: "Does homebrew still do that insane thing when you want to upgrade a single package it tells you 'hold my beer' and starts instal…”

   proof ↗⚑ flag

   Bun (package manager)✓fullclaimed7/10

   Docs confirm bun install writes package.json/bun.lock automatically, migrates other lockfiles, supports --frozen-lockfile for reproducible installs, and never touches network beyond cache (docs-2,5,35,38), which is exactly the safe manifest/lockfile-rewrite behavior an agent needs instead of hand-editing. Missing for 10: explicit doc citations for the `bun add`, `bun remove`, and `bun upgrade` subcommands themselves (only `bun install` and `bun pm` are directly quoted), and no independent/hands-on evidence specifically validating add/remove/upgrade correctness.

   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
   • [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
   • [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”

   proof ↗⚑ flag

Structured output

1. ai-native userGet machine-readable (JSON) output from core commands so an agent can parse results instead of scraping text

   weight 2 · round drawn
   Homebrew—none0/10

   The evidence pack contains no mention of any `--json` flag or machine-readable output mode for Homebrew commands (e.g., `brew info --json`, `brew list --json`); all documented behavior is text-based CLI output, and probes for machine-readable API artifacts (llms.txt, openapi.json) explicitly failed. Since this axis is a fair question for a CLI package manager but no supporting evidence exists, it counts as none.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.brew.sh/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.brew.sh/openapi.json, https://docs.brew.sh/swagger.json, https://docs.brew.sh/api/opena…”
   • [probe] “official CLI documented at https://docs.brew.sh/Manpage”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   No evidence in the pack shows any Bun package-manager command (install, pm ls, audit, outdated, pack, etc.) offering a --json or machine-readable output flag; docs only describe human-readable text output and lockfile formats. No JSON/agent-parseable output capability is documented.

   ⚑ flag

2. ai-native userPoint an agent at a documented, text-based lockfile format it can read and diff

   weight 1 · round to Bun (package manager)
   Homebrew~partialclaimed6/10

   Homebrew's Brewfile is a plain-text, human-readable manifest that can be generated (`brew bundle dump`), checked, and diffed like other dependency manifests (package.json, Gemfile), and docs explicitly draw that analogy. However, it's a declarative bundle manifest rather than a strict version-pinned lockfile, and there's no evidence of agent-specific tooling, schema documentation, or guidance for programmatic diffing/parsing by AI agents. missing for 10: explicit lockfile/versioning semantics (vs. just current-state snapshot), documented schema for machine parsing, agent-oriented tooling or examples of AI agents reading/diffing Brewfiles.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [claimed-docs] “The Brewfile's dependencies are satisfied.”

   proof ↗⚑ flag

   Bun (package manager)✓fullclaimed9/10

   Bun's default lockfile format bun.lock is explicitly text-based (v1.2+) and documented, replacing the binary bun.lockb, and docs market it as 'a lockfile you can read'—directly matching the story of a documented, diffable, text lockfile an agent could parse. Missing for 10: no independent/hands-on confirmation of agent tooling actually diffing bun.lock or third-party validation of its readability/diff-friendliness beyond vendor docs.

   • [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Bun (package manager)
   Homebrew—none0/10

   A direct probe found no llms.txt (404) and no agent-oriented API docs (openapi endpoints all 404); no evidence of agent-oriented documentation exists elsewhere in the pack.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.brew.sh/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.brew.sh/openapi.json, https://docs.brew.sh/swagger.json, https://docs.brew.sh/api/opena…”

   proof ↗⚑ flag

   Bun (package manager)✓fullprobed9/10

   Bun ships a live llms.txt (HTTP 200) plus markdown-rendered docs (docs.md), directly enabling an agent to be pointed at agent-oriented documentation, confirmed via direct probes rather than just claims. missing for 10: no independent/community confirmation that agents actually consume it successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Homebrew
   Homebrew✓fullprobed7/10

   Homebrew's CLI supports non-interactive automation via `NONINTERACTIVE=1` for installs, and `brew bundle`/Brewfile workflows are explicitly designed for reproducible, scriptable dependency installs suitable for CI/dev environments. The official manpage documents these flags and commands, confirming headless operation is a first-class use case. Missing for 10: explicit CI/GitHub Actions integration examples or docs, and independent hands-on confirmation of CI usage.

   • [claimed-docs] “prepend `NONINTERACTIVE=1` to the installation command”
   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Adding a `Brewfile` to a project’s repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “Run your shell in a `brew bundle exec` environment.”
   • [probe] “official CLI documented at https://docs.brew.sh/Manpage”

   proof ↗⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun's CLI supports scriptable, non-interactive flags like --frozen-lockfile for reproducible installs, production mode installs, and global cache usage, which are all suitable for CI pipelines, and its speed claims are documented for automation contexts. However, there is no explicit CI/headless documentation, no GitHub Actions examples, no CI exit-code/error-handling docs, and community evidence shows real-world install flakiness in CI-like conditions (crashes, lockfile issues). missing for 10: explicit CI/headless usage docs or examples, GitHub Actions/official CI integration guide, evidence of stable non-interactive automation behavior, and independent corroboration of headless reliability in pipelines.

   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “To install in production mode (without `devDependencies`):”
   • [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to Bun (package manager)
   Homebrew~partialprobed5/10

   Homebrew ships a well-documented official CLI (`brew`, see manpage) with automation-friendly features like `NONINTERACTIVE=1` for scripted/agentic use, but there is no evidence of AI-native affordances such as machine-readable output modes, an llms.txt, or agent-specific integration docs — in fact the llms.txt probe returned 404. missing for 10: structured/JSON output documentation for programmatic agent consumption, an llms.txt or AI-agent discovery file, explicit agent/automation-oriented documentation beyond generic non-interactive flag.

   • [probe] “official CLI documented at https://docs.brew.sh/Manpage”
   • [claimed-docs] “prepend `NONINTERACTIVE=1` to the installation command”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.brew.sh/llms.txt”

   proof ↗⚑ flag

   Bun (package manager)✓fullprobed9/10

   Bun ships an official, extensively documented CLI (bun install, bunx, bun pm, etc.) that is the product's primary interface, and Bun even exposes machine-readable docs (llms.txt, docs.md) explicitly for AI/agent consumption. Community evidence corroborates ergonomic scripting/automation use (comm-8, comm-9). Missing for 10: no first-party documentation of CLI use within specific agent frameworks or automation harnesses beyond anecdotal community reports.

   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
   • [claimed-docs] “bunx cowsay 'Hello, world!' # execute a package”
   • [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
   • [probe] “official CLI documented at https://bun.com/docs/cli/install”
   • [community] “Really loving Bun these days. Was really pleasantly surprised using their shell scripting API in typescript - single file, shebang line, str…”
   • [community] “It is also my first choice now. Especially due to built in SQLite support. Also recently needed to write a simple script to dump some data t…”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to Bun (package manager)
   Homebrew~partialprobed3/10

   Homebrew exposes a well-documented CLI (Manpage) that can be scripted or invoked programmatically by an AI agent, but there is no dedicated public API, OpenAPI spec, or llms.txt — probes explicitly returned 404s for these. Missing for 10: a machine-readable API spec (OpenAPI/GraphQL), an llms.txt or agent-friendly interface, and any first-party SDK for programmatic (non-CLI) access.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.brew.sh/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.brew.sh/openapi.json, https://docs.brew.sh/swagger.json, https://docs.brew.sh/api/opena…”
   • [probe] “official CLI documented at https://docs.brew.sh/Manpage”
   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”

   proof ↗⚑ flag

   Bun (package manager)~partialprobed5/10

   Bun ships extensively documented CLI commands (install, pm, audit, workspaces, etc.) and even exposes machine-readable docs via llms.txt/docs.md that an AI agent could parse to drive it, but there is no formal public API (REST/OpenAPI/SDK) for programmatic control—OpenAPI probes all 404. This is CLI-driven automation, not a genuine API contract for agentic integration. missing for 10: a documented HTTP/OpenAPI or SDK-style API, first-party guidance on programmatic/agent use beyond shell invocation, independent confirmation of AI agents successfully driving it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”
   • [probe] “official CLI documented at https://bun.com/docs/cli/install”
   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Bun (package manager)
   Homebrew—none0/10

   Direct probes for OpenAPI/swagger specs and llms.txt all return 404, and no evidence of any machine-readable API spec exists in the docs; Homebrew's docs are man-page style, not an API spec.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.brew.sh/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.brew.sh/openapi.json, https://docs.brew.sh/swagger.json, https://docs.brew.sh/api/opena…”

   proof ↗⚑ flag

   Bun (package manager)~partialprobed4/10

   Bun has no REST/HTTP API to describe via a formal OpenAPI spec (it's a local CLI/package manager), but probes confirm it exposes an AI-consumable machine-readable docs equivalent (llms.txt and docs.md) rather than a true OpenAPI/swagger file, which 404s on all standard paths. missing for 10: an actual OpenAPI/swagger spec, any documented API schema, independent confirmation that llms.txt is treated as a valid 'equivalent' by AI tooling.

   • [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
   • [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Homebrew
   Homebrew✓fullcommunity8/10

   Homebrew's Brewfile/`brew bundle` system (install/dump/check/exec) lets a user declare and act on many formulae, casks, taps, and other package types in one bulk operation, and community reports confirm that operations like `brew upgrade` do act across many installed items at once. This is scriptable, non-interactive (NONINTERACTIVE=1) and CLI-driven, making it usable by AI-native automation. Missing for 10: no first-party example of an AI agent orchestrating bulk operations, and no benchmark/independent validation of bulk-operation reliability at scale.

   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [claimed-docs] “prepend `NONINTERACTIVE=1` to the installation command”
   • [community] “User reports that 'brew upgrade' started updating ALL casks, even ones marked 'auto_updates: true' in the Cask JSON API, calling it new defa…”
   • [community] “User asks: "Does homebrew still do that insane thing when you want to upgrade a single package it tells you 'hold my beer' and starts instal…”

   proof ↗⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun's CLI supports several genuine bulk operations useful for automation: filtering/installing across many workspaces with `--filter` or glob patterns (bun-docs-9, bun-docs-21, bun-docs-32), bulk vulnerability remediation via `bun audit --fix` upgrading every vulnerable package at once (bun-docs-7), and shared version catalogs applied across many packages (bun-docs-11, bun-docs-22). These are documented, scriptable CLI behaviors well-suited to programmatic/AI-driven automation, but there is no explicit AI-native batch API, no independent corroboration of large-scale bulk runs, and community threads raise open monorepo-script gaps (bun-comm-10). Missing for 10: a dedicated programmatic/bulk API beyond CLI flags, independent hands-on evidence of large-scale multi-package operations succeeding, and confirmation of per-package script execution at scale in monorepos.

   • [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”
   • [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
   • [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json`”
   • [claimed-docs] “Install dependencies for only `pkg-a` in `./packages/pkg-a`”
   • [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json` and reference them …”
   • [claimed-docs] “In a monorepo, you can install the dependencies for a subset of packages using the `--filter` flag.”
   • [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”

   proof ↗⚑ flag

Platform parity

1. developerUse the same workflow and config on macOS, Linux, and Windows

   weight 2 · round to Homebrew
   Homebrew✓fullclaimed9/10

   Homebrew explicitly documents supporting macOS, Linux, and WSL/Windows with the same package manager and CLI, and Brewfile/brew bundle provides a portable config format for reproducing dev environments across platforms. missing for 10: independent hands-on verification of identical workflow parity (e.g., no community report confirming full feature parity across all three OSes, only vendor docs).

   • [claimed-docs] “Use the same package manager to manage your macOS, Linux and Windows systems”
   • [claimed-docs] “Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.”
   • [claimed-docs] “Install up-to-date versions of software when your host distribution is old”
   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”

   proof ↗⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun's docs confirm platform-aware install behavior (e.g., hardlink-based node_modules specifically on Linux and Windows) and its package manager is documented to work as a drop-in for npm/yarn/pnpm across projects (bun-docs-25, bun-docs-26). However, community reports flag Windows-specific install bugs/crashes when switching between WSL and native Windows, suggesting the workflow isn't perfectly uniform across all three OSes (bun-comm-7), while other users confirm smooth cross-platform monorepo use (bun-comm-6). Missing for 10: explicit macOS-specific documentation, first-party statement of full config/workflow parity across all three OSes, and resolution of the reported Windows install bugs.

   • [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”

   proof ↗⚑ flag

Extensibility

1. developerExtend the manager through third-party taps, overlays, plugins, or backends

   weight 1 · round to Homebrew
   Homebrew✓fullcommunity8/10

   Homebrew documents multiple extensibility mechanisms: third-party taps (`brew tap`/`untap`) that add external formula/cask repositories and even external commands, and Brew Bundle's Brewfile which acts as a plugin-like backend system supporting non-Homebrew package types (Mac App Store, VSCode extensions, Go, Cargo, uv, Flatpak, WinGet, Krew, npm). Community evidence (Trail of Bits audit, tap-trust feature reception) corroborates the tap ecosystem exists and is actively used, though one user notes self-hosting a tap is harder than hosting a plain file repo, a minor friction point rather than a failure of the capability. Missing for 10: independent hands-on validation of writing a custom bundle 'backend'/plugin beyond the built-in list, and clearer docs on extending via custom external commands.

   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”
   • [claimed-docs] “The `brew tap` command adds repositories that Homebrew can use for formulae, casks and external commands.”
   • [claimed-docs] “`brew tap <user>/<repository>` clones `https://github.com/<user>/homebrew-<repository>` into Homebrew’s tap directory.”
   • [claimed-docs] “`brew tap <user>/<repository>` clones `https://github.com/<user>/homebrew-<repository>` into Homebrew's tap directory”
   • [claimed-docs] “brew untap <user>/<repository> [...] removes one or more taps. Homebrew deletes the local repositories and no longer loads their contents.”
   • [community] “"Hell yeah, tap trust!!!" — positive reaction to new brew tap trust feature described in docs.brew.sh/Tap-Trust.”
   • [community] “User who tried hosting a Homebrew tap found it much harder than hosting apt/yum repos, since it requires running a git server rather than ju…”
   • [community] “Trail of Bits auditor: "the findings on Homebrew were not inconsistent with what I'd expect to find on any similarly sized userspace package…”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   The evidence pack covers Bun's install features (workspaces, catalogs, overrides, audit, cache) but contains no mention of a plugin/tap/backend extension mechanism for the package manager itself, unlike e.g. npm plugins or Homebrew taps.

   ⚑ flag

Private registries

1. platform-engineerPoint the manager at private registries or mirrors with scoped authentication

   weight 2 · round to Homebrew
   Homebrew~partialcommunity4/10

   Homebrew's tap mechanism lets platform engineers add custom Git repositories as package sources (docs-5, 19, 22, 34), which is the closest analog to pointing at a private registry, and community evidence confirms taps can be self-hosted (comm-14). However, there is no evidence in the pack of scoped authentication mechanisms, private mirror configuration (e.g. bottle/mirror domain overrides), or credential management for private taps — comm-14 actually highlights that self-hosting a tap is harder than a standard package mirror since it requires running a git server rather than a simple static/CDN host. Missing for 10: documented support for authenticated/private mirrors, scoped credential/token configuration, and any first-party guidance on enterprise registry mirroring.

   • [claimed-docs] “The `brew tap` command adds repositories that Homebrew can use for formulae, casks and external commands.”
   • [claimed-docs] “`brew tap <user>/<repository>` clones `https://github.com/<user>/homebrew-<repository>` into Homebrew’s tap directory.”
   • [claimed-docs] “`brew tap <user>/<repository>` clones `https://github.com/<user>/homebrew-<repository>` into Homebrew's tap directory”
   • [claimed-docs] “brew untap <user>/<repository> [...] removes one or more taps. Homebrew deletes the local repositories and no longer loads their contents.”
   • [community] “User who tried hosting a Homebrew tap found it much harder than hosting apt/yum repos, since it requires running a git server rather than ju…”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   The evidence pack covers install speed, lockfiles, workspaces, caching, audit, and pm subcommands, but contains no mention of configuring private registries, mirrors, scoped registries, or authentication tokens (e.g., via bunfig.toml or .npmrc equivalents). This is a fair capability for a package manager to be judged on, but nothing in the pack demonstrates it.

   ⚑ flag

Registry

1. developerInstall almost anything I need from a large, actively maintained package registry or repository

   weight 2 · round to Homebrew
   Homebrew✓fullcommunity9/10

   Homebrew's core value proposition is a large, actively maintained formula/cask registry, taps for extending it, and independent evidence (comm-18) confirms broad package availability and fast version updates versus alternatives like MacPorts; docs also show bundler support for many ecosystems (npm, cargo, Go, etc.) broadening what can be installed. Some community friction exists around packaging difficulty and stale taps (homebrew-comm-6, homebrew-comm-7) but these are edge-case caveats, not evidence the registry itself fails to deliver broad package availability. Missing for 10: independent quantitative data on total package count/registry size and update cadence beyond anecdote.

   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”
   • [claimed-docs] “The `brew tap` command adds repositories that Homebrew can use for formulae, casks and external commands.”
   • [claimed-docs] “`brew tap <user>/<repository>` clones `https://github.com/<user>/homebrew-<repository>` into Homebrew’s tap directory.”
   • [claimed-docs] “Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.”
   • [community] “Long-time user recalls choosing Homebrew over MacPorts because 'brew had and has many more packages available, brew updates versions more qu…”
   • [community] “User describes switching entire dev environment from Homebrew+pipx+npm to mise, citing zero version lag and being able to install any arbitr…”
   • [community] “User recalls packaging a Python app for Homebrew as painful: importing ~50 dependencies as 'resources', building from source, declaring tool…”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity8/10

   Bun is explicitly designed as an npm-compatible package manager, installing directly from the npm registry (the largest JS package ecosystem) with lockfile migration from npm/yarn/pnpm, global installs, bunx for one-off execution, and workspace/monorepo support, all documented extensively. Community reports corroborate real-world usage of `bun install` against npm packages, with some install reliability bugs and edge-case runtime incompatibilities (unrelated to registry breadth) noted as caveats. Missing for 10: independent benchmark of registry breadth/failure-rate across large package sets, and resolution of noted install crash bugs.

   • [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
   • [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
   • [claimed-docs] “bunx cowsay 'Hello, world!' # execute a package”
   • [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
   • [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
   • [community] “I used bun for the first time last week. It was awesome! The built-in server and SQLite meant i didn't need any dependencies besides bun its…”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”

   proof ↗⚑ flag

Bootstrap

1. developerBootstrap a fresh clone with one command that installs everything the project declares

   weight 2 · round drawn
   Homebrew✓fullcommunity8/10

   Homebrew's Brewfile + `brew bundle install` lets a developer declare formulae, casks, taps, and other dependencies in a repo file and install them all with a single command (`brew bundle install`), with `brew bundle check`/`dump` supporting reproducibility workflows. missing for 10: independent hands-on confirmation of a full 'fresh clone bootstrap' scenario end-to-end, and community evidence raises concerns about upgrade behavior/version pinning that slightly undercut strict reproducibility guarantees.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [claimed-docs] “The Brewfile's dependencies are satisfied.”
   • [community] “User describes switching entire dev environment from Homebrew+pipx+npm to mise, citing zero version lag and being able to install any arbitr…”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity8/10

   Bun's `bun install` reads package.json/workspaces and lockfile, migrates other lockfiles automatically, and supports `--frozen-lockfile` for reproducible installs, directly matching the one-command bootstrap story; community posts also confirm real-world use as a package manager. Missing for 10: independent benchmarking of fresh-clone bootstrap reliability across OSes, and some community reports of install crashes/edge-case bugs (old lockfiles, WSL/Windows switching) that add minor caveats.

   • [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “With workspaces, you develop several independent packages in a single repository, a _monorepo_.”
   • [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”

   proof ↗⚑ flag

Lockfiles

1. platform-engineerEnforce a frozen/immutable lockfile mode that fails the install when the manifest and lockfile disagree

   weight 2 · round to Bun (package manager)
   Homebrew—none0/10

   Homebrew's Brewfile/bundle mechanism only supports `brew bundle check` (report whether the current install differs) and `brew bundle install` (reconcile) — there is no documented strict/immutable mode that fails a CI install when manifest and lockfile disagree, and Brewfile itself is not a version-locking lockfile. Community commentary even contrasts Homebrew's lack of reproducibility with tools like Nix, reinforcing the absence of this capability.

   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “The Brewfile's dependencies are satisfied.”
   • [community] “User switched back to Homebrew from Nix, citing better package support/maintenance, better macOS support, and better UX, despite missing Nix…”
   • [community] “"I recently switched _back_ to Homebrew from Nix... Brew has won me back" despite liking Nix's reproducibility, citing better package mainte…”

   proof ↗⚑ flag

   Bun (package manager)✓fullclaimed9/10

   Bun's docs explicitly document `--frozen-lockfile` for reproducible installs, stating Bun installs the exact versions in the lockfile and does not update it, which matches the enforcement behavior platform engineers need; the lockfile format and reproducibility model are also well documented. missing for 10: explicit confirmation/example of the install failing (non-zero exit) when manifest and lockfile disagree, and independent/community corroboration of this specific flag's failure behavior.

   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”

   proof ↗⚑ flag

2. developerInstall dependencies from a lockfile and get the exact same resolved versions on every machine

   weight 3 · round to Bun (package manager)
   Homebrew!disputedcontradicted4/10

   Homebrew's Brewfile (docs-1/13/20, docs-2/21/32, docs-26) lets you snapshot and reinstall dependency lists across machines, similar to package.json, but it records formula/cask names rather than pinned exact versions with hashes — there's no evidence of a true version-locking mechanism. Community evidence directly contradicts the reproducibility claim: users note being 'screwed too many times on mandatory upgrades I couldn't pin' (comm-5) and explicitly cite 'missing Nix's reproducibility' when comparing to Homebrew (comm-13, comm-15). Missing for 10: documented exact-version pinning/lockfile hash verification, evidence that `brew bundle install` reproduces identical resolved versions rather than latest-available versions matching names.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [community] “User says they stopped using Homebrew after being 'screwed too many times on mandatory upgrades I couldn't pin,' switching to a combination …”
   • [community] “User switched back to Homebrew from Nix, citing better package support/maintenance, better macOS support, and better UX, despite missing Nix…”
   • [community] “"I recently switched _back_ to Homebrew from Nix... Brew has won me back" despite liking Nix's reproducibility, citing better package mainte…”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity8/10

   Bun documents a lockfile (bun.lock) that captures resolved versions and an explicit --frozen-lockfile flag that installs exact versions without updating, directly matching the reproducibility story; it also auto-migrates from npm/yarn/pnpm lockfiles. A community report notes occasional install crashes tied to stale lockfiles/node_modules, a minor real-world caveat rather than a fundamental contradiction. Missing for 10: independent large-scale reproducibility testing/benchmarks and resolution of the noted crash bug reports.

   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”

   proof ↗⚑ flag

Pinning

1. developerPin exact versions of packages and tools per project and have the manager respect those pins

   weight 3 · round to Bun (package manager)
   Homebrew!disputedcontradicted3/10

   Homebrew docs show a Brewfile mechanism for encoding project dependencies and installed-state snapshots (brew bundle dump/install), but Brewfiles record package names, not exact pinned versions, and there's no documented per-project version-pinning mechanism respected by the manager. Community evidence explicitly contradicts this story: a user reports being 'screwed too many times on mandatory upgrades I couldn't pin' and switching to Mise, another complains Homebrew lacks a standard way to install/pin multiple versions of tools like node/php/Python, relying on pyenv/nvm instead. missing for 10: documented per-formula/project version pinning respected across installs, evidence Brewfile can lock exact versions, resolution of the community-reported pinning failures.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [claimed-docs] “You can check if a `brew bundle install` will do anything by running: $ brew bundle check”
   • [community] “User says they stopped using Homebrew after being 'screwed too many times on mandatory upgrades I couldn't pin,' switching to a combination …”
   • [community] “User describes switching entire dev environment from Homebrew+pipx+npm to mise, citing zero version lag and being able to install any arbitr…”
   • [community] “User wishes for a standard Homebrew way to install multiple versions of node, php and Python, currently relying on pyenv/nvm alongside Homeb…”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity9/10

   Bun generates a lockfile (bun.lock) that pins exact resolved versions, and `bun install --frozen-lockfile` explicitly installs those exact versions without updating, satisfying per-project version pinning; overrides/resolutions further let developers force exact versions across the tree. missing for 10: independent/hands-on confirmation specifically testing that frozen-lockfile pins are honored under edge cases (only general community praise/issues about monorepo installs, not pin-specific verification).

   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
   • [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. Both specify a version range for _metadependencies_”
   • [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`.”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”

   proof ↗⚑ flag

Compatibility

1. switcherKeep using familiar commands and interface conventions from the incumbent tool while adopting this manager

   weight 2 · round to Bun (package manager)
   Homebrew~partialcommunity4/10

   Homebrew's Brewfile is explicitly designed to mirror familiar conventions from other ecosystems (package.json, Gemfile, requirements.txt) and its bundler can manage npm, Cargo, Go, uv, WinGet packages, easing conceptual migration, and community comments show users moving between Homebrew and MacPorts/Nix citing familiar UX. However there is no evidence of command-level compatibility (e.g., aliasing apt/yum/MacPorts commands) or an explicit migration guide for switchers. Missing for 10: command-alias/compat layer for incumbent tool syntax, dedicated switcher migration documentation, independent verification of command familiarity claims.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Bundler for non-Ruby dependencies from Homebrew formulae, Homebrew casks, Mac App Store dependencies, VSCode (and forks/variants) extensions…”
   • [claimed-docs] “Adding a `Brewfile` to a project’s repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [community] “User switched back to Homebrew from Nix, citing better package support/maintenance, better macOS support, and better UX, despite missing Nix…”
   • [community] “"I recently switched _back_ to Homebrew from Nix... Brew has won me back" despite liking Nix's reproducibility, citing better package mainte…”
   • [community] “Long-time user recalls choosing Homebrew over MacPorts because 'brew had and has many more packages available, brew updates versions more qu…”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity8/10

   Bun explicitly positions itself as a drop-in replacement for npm/yarn/pnpm, supporting familiar commands (`bun install`, `bunx`), automatic migration of existing `yarn.lock`/`package-lock.json`/`pnpm-lock.yaml` files, and npm-compatible fields like `overrides`/`resolutions`, letting switchers keep muscle-memory commands and config conventions (bun-docs-1, bun-docs-2, bun-docs-17, bun-docs-18, bun-docs-26, bun-docs-31). Community members confirm they use Bun purely as a package manager without switching runtimes, easing adoption (bun-comm-2, bun-comm-4). Missing for 10: independent confirmation of complete command-surface parity for less common workflows, and some community reports of monorepo/lockfile migration friction and crashes that qualify a fully seamless switch (bun-comm-7, bun-comm-10).

   • [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
   • [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
   • [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. Both specify a version range for _metadependencies_”
   • [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
   • [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
   • [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
   • [community] “Didn't prevent me from switching to Bun as the cost is 0.”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
   • [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”

   proof ↗⚑ flag

Migration

1. switcherMigrate an existing project from the incumbent tool with documented import or conversion tooling

   weight 2 · round to Bun (package manager)
   Homebrew—none0/10

   Homebrew's Brewfile lets you snapshot/replay Homebrew's own installed state and is likened to package.json/Gemfile, but there's no documented tool for importing/converting an existing project's dependency manifest from another package manager (e.g., apt, MacPorts, Nix) into Homebrew. Community evidence only shows anecdotal switching to/from Homebrew, not an official conversion tool.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “`brew bundle dump` is Homebrew's installed-state snapshot command: it records supported installed formulae, casks, taps and other package ty…”
   • [community] “User switched back to Homebrew from Nix, citing better package support/maintenance, better macOS support, and better UX, despite missing Nix…”
   • [community] “User switched from Homebrew to MacPorts a few years ago and 'couldn't be happier.'”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity7/10

   Bun documents drop-in npm compatibility ("bun install in any Node.js project") and automatic migration of existing yarn.lock, package-lock.json, and pnpm-lock.yaml files into bun.lock, directly addressing incumbent-tool migration. Community reports confirm it's usable as a pure package-manager swap, though some note lockfile/node_modules switching bugs and monorepo migration uncertainty. Missing for 10: independent case studies of full large-project migrations, and resolution of reported install crashes when switching lockfile formats.

   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”
   • [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles:”
   • [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
   • [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
   • [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
   • [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
   • [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”

   proof ↗⚑ flag

1. ai-native userRead the product's source under an open license

   weight 2 · round to Homebrew
   Homebrew~partialclaimed4/10

   The evidence pack shows Homebrew's source code is publicly hosted on GitHub (homebrew-gh-1: github.com/Homebrew/brew), which supports the ability to read the source, but no evidence explicitly states the license terms under which it is distributed. missing for 10: explicit license documentation (e.g., BSD-2-Clause) referenced in the evidence pack, independent confirmation of license compliance.

   • [github] “perform a strict audit on a package you use e.g. `brew audit --strict ffmpeg` for FFmpeg”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   The evidence pack contains no reference to Bun's source code repository, license, or any statement about open-source availability — all citations are docs/CLI usage examples or community sentiment about performance, none addressing openness of the source. Missing for 10: any mention of a GitHub repo, license (e.g., MIT), or contribution/source-availability documentation.

   ⚑ flag

Benchmarks

1. developerSee published benchmarks or measured numbers backing the manager's speed claims

   weight 1 · round to Bun (package manager)
   Homebrew—none0/10

   No published benchmarks or measured performance numbers appear anywhere in the evidence; only anecdotal community remarks about upgrade speed (e.g., 'most pleasant brew upgrade session') and a Bootsnap env var mention, with no actual data or benchmark reports cited.

   ⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun's docs and marketing page publish concrete speed claims (25x/30x faster) and even a specific measured number comparison (bun v1.4 0.21s vs npm v12.0.2 4.45s), which goes beyond a bare marketing slogan. However, these are all first-party vendor numbers with no disclosed benchmark methodology (hardware, package set, versions) and no independent third-party benchmark reproduction in the evidence; community comments only vaguely corroborate perceived speedups (e.g., isolated installs 10-20x faster on Windows) without rigorous numbers. Missing for 10: independent/third-party benchmark verification, transparent methodology/environment details for the vendor numbers.

   • [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
   • [claimed-docs] “bun v1.4 0.21s ... npm v12.0.2 4.45s”
   • [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”

   proof ↗⚑ flag

Binary caching

1. developerInstall prebuilt binary packages from a cache instead of compiling from source

   weight 3 · round to Homebrew
   Homebrew✓fullclaimed8/10

   Homebrew's Bottles documentation explicitly describes that formulae define prebuilt binary bottles matching the user's system architecture, which are downloaded and installed automatically instead of building from source, and casks similarly install upstream prebuilt binaries. This is a core, well-documented feature (first-party docs) though independent hands-on corroboration of bottle-vs-source performance specifically is thin. missing for 10: independent/hands-on verification of bottle cache hit rates or fallback-to-source behavior in practice.

   • [claimed-docs] “When the formula being installed defines a bottle matching your system, it will be downloaded and installed automatically when you run `brew…”
   • [claimed-docs] “Use `--bottle-arch=` only when the formula intentionally requires another architecture and its compatibility has been reviewed.”
   • [claimed-docs] “Casks are package definitions that install upstream pre-built binaries such as applications, fonts and plugins.”
   • [claimed-docs] “It installs each package into its own keg inside the Cellar, then symlinks its files into the prefix”

   proof ↗⚑ flag

   Bun (package manager)✓fullcommunity7/10

   Bun's docs describe a global package cache (~/.bun/install/cache) with hardlinked installs, and explicitly state a required dependency not found in the cache errors rather than falling back to compiling/fetching from source, supporting fast reuse instead of source builds. Community and benchmark evidence corroborate large speedups from this caching behavior. missing for 10: explicit documentation of prebuilt *binary* (native addon) caching versus source compilation, and independent hands-on verification of that specific scenario.

   • [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
   • [claimed-docs] “a required dependency that is not cached is an error”
   • [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
   • [claimed-docs] “bun v1.4 0.21s ... npm v12.0.2 4.45s”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”

   proof ↗⚑ flag

Ci speed

1. platform-engineerMake CI installs fast with a documented cache-restore setup and offline-capable installs

   weight 3 · round to Bun (package manager)
   Homebrew—none0/10

   Evidence shows bottles (precompiled binaries) speed up installs and Brewfile enables reproducible dependency lists, but there is no documented CI cache-restore setup (e.g. HOMEBREW_CACHE guidance, GitHub Actions cache integration) or offline-capable install mode described anywhere in the pack.

   ⚑ flag

   Bun (package manager)~partialclaimed7/10

   Bun documents a global package cache (~/.bun/install/cache), a strict offline mode where missing cached packages error instead of hitting the network, and --frozen-lockfile for reproducible installs — the core primitives for fast, cache-restorable, offline-capable CI installs. However there's no explicit CI-specific guide (e.g. GitHub Actions cache-restore recipe) tying these primitives together for a platform engineer. Missing for 10: a documented CI/CD cache-restore workflow example, independent benchmarks of cache-restore behavior in CI.

   • [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
   • [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
   • [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
   • [claimed-docs] “a required dependency that is not cached is an error”
   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”

   proof ↗⚑ flag

Disk efficiency

1. developerRely on a shared content-addressable store so the same dependency version is stored once on disk across all projects

   weight 2 · round to Bun (package manager)
   Homebrew~partialcommunity4/10

   Homebrew's docs show a single shared install location (the Cellar) where each formula version is installed once and then symlinked into the prefix, meaning multiple projects on the same machine reuse the same on-disk copy rather than duplicating it (homebrew-docs-28). However, this is a global install directory, not a true content-addressable store keyed by build hash (unlike Nix/Guix), and community commentary explicitly contrasts Homebrew's lack of Nix-style reproducibility/content-addressing (homebrew-comm-13, homebrew-comm-15) even while praising Homebrew's UX. Missing for 10: explicit documentation of content-addressed/hashed store paths, evidence of per-project isolation without conflicts, and independent verification of dedup behavior across projects.

   • [claimed-docs] “It installs each package into its own keg inside the Cellar, then symlinks its files into the prefix”
   • [community] “User switched back to Homebrew from Nix, citing better package support/maintenance, better macOS support, and better UX, despite missing Nix…”
   • [community] “"I recently switched _back_ to Homebrew from Nix... Brew has won me back" despite liking Nix's reproducibility, citing better package mainte…”

   proof ↗⚑ flag

   Bun (package manager)✓fullclaimed9/10

   Bun documents a global content-addressable cache at ~/.bun/install/cache storing every downloaded package once, and on Linux/Windows uses hardlinks so a package's contents exist in a single location on disk while being linked into each project's node_modules, directly matching the story. Missing for 10: independent hands-on benchmark/verification specifically confirming cross-project single-copy storage (community evidence discusses install speed/reliability but not disk dedup directly).

   • [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
   • [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”

   proof ↗⚑ flag

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round to Homebrew
   Homebrew✓fullclaimed8/10

   Homebrew documents built-in analytics controls: `brew analytics off` fully disables anonymous aggregate usage tracking, and the manpage describes this control explicitly. This directly satisfies opting out of telemetry. Missing for 10: independent/hands-on confirmation that the opt-out reliably stops all data collection (only first-party docs cited, no third-party verification of actual network behavior).

   • [claimed-docs] “Control Homebrew's anonymous aggregate user behaviour analytics.”
   • [claimed-docs] “`brew analytics off` Turn Homebrew’s analytics off.”
   • [claimed-docs] “Control Homebrew’s anonymous aggregate user behaviour analytics.”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   No evidence in the pack discusses telemetry, usage tracking, or an opt-out mechanism for Bun's CLI/package manager; the docs cover install, cache, workspaces, audit, etc., but nothing about data collection or privacy settings.

   ⚑ flag

Auditing

1. platform-engineerAudit installed dependencies for known vulnerabilities directly from the CLI

   weight 3 · round to Bun (package manager)
   Homebrew—none0/10

   The only related evidence is `brew audit --strict`, which is a formula-quality/style linter for package definitions, not a CVE/vulnerability database scan of installed dependencies. No evidence pack item shows Homebrew cross-referencing installed formulae/casks against known-vulnerability databases (unlike `npm audit` or `pip-audit`). missing for 10: any CVE/vulnerability database integration, a documented security-audit subcommand, and evidence of scanning installed packages (vs. formula source) for known vulnerabilities.

   • [github] “perform a strict audit on a package you use e.g. `brew audit --strict ffmpeg` for FFmpeg”

   proof ↗⚑ flag

   Bun (package manager)✓fullclaimed8/10

   Bun ships a dedicated `bun audit` CLI command that reads the lockfile, checks packages against the npm advisory endpoint, and prints a vulnerability report, with `bun audit --fix` to auto-remediate — directly matching the platform-engineer's need to audit dependencies from the CLI. missing for 10: no independent/hands-on community corroboration of `bun audit` in practice, and no detail on report format or CI integration examples.

   • [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
   • [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”

   proof ↗⚑ flag

Hardening

1. platform-engineerTurn on protections against malicious packages, such as blocking lifecycle scripts or enforcing a minimum release age

   weight 2 · round to Bun (package manager)
   Homebrew~partialcommunity3/10

   Homebrew documents a 'tap trust' feature to restrict installs to trusted taps and `brew audit --strict` for auditing formula quality/security, which are adjacent supply-chain protections, but there is no evidence of the specific controls named in the story—blocking lifecycle/install scripts or enforcing a minimum release age before a package can be installed. missing for 10: documented ability to disable/block formula install scripts, a minimum-release-age gate or similar time-delay policy, and any admin-facing config toggle for these specific protections.

   • [claimed-docs] “Install a fully qualified item to trust only that item:”
   • [community] “"Hell yeah, tap trust!!!" — positive reaction to new brew tap trust feature described in docs.brew.sh/Tap-Trust.”
   • [github] “perform a strict audit on a package you use e.g. `brew audit --strict ffmpeg` for FFmpeg”

   proof ↗⚑ flag

   Bun (package manager)~partialclaimed6/10

   Bun ships strong default protection against malicious lifecycle scripts: it does not execute postinstall/lifecycle scripts by default, and platform-engineers can allowlist trusted packages via `trustedDependencies` (bun-docs-19, bun-docs-4). There is also a supply-chain audit command that checks the npm advisory database (bun-docs-6, bun-docs-7). However, no evidence exists of a 'minimum release age' enforcement feature, which is explicitly part of the user story. Missing for 10: minimum-release-age enforcement/config, independent/hands-on confirmation of the lifecycle-script blocking behavior in practice.

   • [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
   • [claimed-docs] “To tell Bun to allow lifecycle scripts for a particular package, add the package to `trustedDependencies` in your package.json.”
   • [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
   • [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”

   proof ↗⚑ flag

Integrity

1. platform-engineerTrust that fetched packages are verified against checksums, signatures, or attestations before they run

   weight 2 · round to Homebrew
   Homebrew~partialcommunity3/10

   Homebrew documents a 'tap trust' mechanism (installing a fully-qualified item to trust only that item) and offers audit tooling (`brew audit --strict`), and a third-party security audit found nothing unusual for a package manager that serves its own binaries — but the evidence pack contains no explicit documentation of checksum, signature, or attestation verification occurring automatically before a package runs. Missing for 10: explicit docs on bottle/source checksum verification, code-signing or SLSA/attestation checks, and independent confirmation these checks are enforced by default at install time.

   • [claimed-docs] “Install a fully qualified item to trust only that item:”
   • [community] “"Hell yeah, tap trust!!!" — positive reaction to new brew tap trust feature described in docs.brew.sh/Tap-Trust.”
   • [github] “perform a strict audit on a package you use e.g. `brew audit --strict ffmpeg` for FFmpeg”
   • [community] “Trail of Bits auditor: "the findings on Homebrew were not inconsistent with what I'd expect to find on any similarly sized userspace package…”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   Bun's docs describe lockfiles, trustedDependencies, blocking of arbitrary postinstall scripts, and an npm-advisory-based audit command, but none of the evidence mentions checksum verification, package signature verification, or provenance/attestation checks before installing or running packages. missing for 10: explicit checksum/integrity hash verification, package signature verification, and supply-chain attestation (e.g. SLSA/sigstore) support.

   • [claimed-docs] “To tell Bun to allow lifecycle scripts for a particular package, add the package to `trustedDependencies` in your package.json.”
   • [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
   • [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
   • [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”

   proof ↗⚑ flag

Runtimes

1. developerInstall and switch language runtimes or tool versions per project from a checked-in config file

   weight 2 · round to Homebrew
   Homebrew!disputedcontradicted3/10

   Docs show Brewfile can declare and install project dependencies via `brew bundle install/check` (docs-1,13,20,26,30,31), which superficially resembles per-project config, but Homebrew installs one global version per formula rather than supporting per-project runtime switching. Community evidence directly contradicts the story: a user explicitly wishes for 'a standard Homebrew way to install multiple versions of node, php and Python' and relies on pyenv/nvm instead (comm-9), and another switched their whole toolchain to mise specifically for arbitrary/multiple version installs Homebrew couldn't provide (comm-6). Missing for 10: native per-project version switching (like asdf/mise/nvm), evidence of Brewfile pinning distinct runtime versions per directory, and any rebuttal to the community reports of this gap.

   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Adding a `Brewfile` to a project’s repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “Adding a `Brewfile` to a project's repository (like you might a `package.json`, `Gemfile` or `requirements.txt`) is a nicer way of encoding …”
   • [claimed-docs] “brew bundle check || brew bundle install”
   • [claimed-docs] “this will take instructions from the Brewfile to run brew install ruby and install Ruby if needed”
   • [community] “User wishes for a standard Homebrew way to install multiple versions of node, php and Python, currently relying on pyenv/nvm alongside Homeb…”
   • [community] “User describes switching entire dev environment from Homebrew+pipx+npm to mise, citing zero version lag and being able to install any arbitr…”

   proof ↗⚑ flag

   Bun (package manager)—none0/10

   The evidence pack covers Bun's package management features (lockfiles, workspaces, caching, audits) but contains no mention of a mechanism to pin or switch Bun/Node runtime versions per project via a checked-in config file (e.g., a .bun-version or engines-based version switcher). This capability is plausible for a JS toolchain tool, but nothing in the docs or community evidence demonstrates it.

   ⚑ flag