Nix 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 to Bun (package manager)
   Nix~partialcommunity4/10

   Nix's CLI commands (nix build, nix-env --upgrade, nix-shell --run) are inherently scriptable and non-interactive by default, and community evidence confirms real-world CI/build-farm usage (nix-comm-9) implying automation compatibility. However, no evidence explicitly documents exit code conventions, structured error output, or agent-oriented non-interactive flags/behavior. Missing for 10: explicit documentation of exit codes, error message formats, and non-interactive/agent-safe flags for install/update commands.

   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “$ nix-env --upgrade --attr nixpkgs.some-package $ nix-env --rollback”
   • [community] “We're using Nix where I work... it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two…”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”
   • [claimed-docs] “`nix run` - run a Nix application”

   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)
   Nix~partialclaimed3/10

   Nix's CLI does expose commands like `nix-env --upgrade` and `--rollback` for changing installed packages and reverting state (nix-docs-4, nix-docs-17), and flakes use a `flake.lock` file, but the evidence never shows dependency-manifest commands analogous to `add`/`remove` (e.g. `nix flake update`, editing `flake.nix` inputs) that would let an agent avoid hand-editing the manifest/lockfile. missing for 10: explicit CLI subcommands for adding/removing flake inputs, evidence of automatic lockfile rewriting, and confirmation these operations are safe/atomic for agent use.

   • [claimed-docs] “$ nix-env --upgrade --attr nixpkgs.some-package $ nix-env --rollback”
   • [claimed-docs] “$ nix-env --rollback”
   • [claimed-docs] “you can roll back to the old version: $ nix-env --rollback”
   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “Create a new flake: # nix flake new hello”

   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
   Nix—none0/10

   No evidence in the pack shows Nix CLI commands offering a --json flag or machine-readable output mode; the manual excerpts describe only text-based commands (nix build, nix run, nix search, nix develop) with no mention of JSON output, and probes for structured API/docs found nothing relevant.

   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “`nix search` - search for packages”
   • [claimed-docs] “`nix run` - run a Nix application”
   • [probe] “official CLI documented at https://nix.dev/manual/nix/2.28/command-ref/new-cli/nix”

   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)
   Nix—none0/10

   The evidence pack contains no mention of Nix's flake.lock file, its JSON/text format, or any documentation aimed at making it readable/diffable by tooling or agents; only flake commands like `nix build`/`nix flake new` are covered without lockfile specifics.

   ⚑ 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)
   Nix—none0/10

   Probes explicitly show llms.txt and machine-readable docs endpoints return 404, and there is no evidence of any agent-oriented docs format for Nix.

   • [probe] “PROBE llms.txt: HTTP 404 at https://nix.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://nix.dev.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://nix.dev/openapi.json, https://nix.dev/swagger.json, https://nix.dev/api/openapi.json, https:…”

   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 drawn
   Nix~partialcommunity6/10

   Nix is a CLI-only tool (nix build, nix run, nix-shell --run, remote builds, binary caches) that is inherently scriptable and used headlessly in CI per community reports (e.g., large-scale Nix CI/deployment usage), but there is no first-party documentation specifically addressing CI integration, headless/non-interactive flags, or official CI templates/actions. missing for 10: dedicated CI/headless documentation, official GitHub Actions or CI integration guide, non-interactive mode flags/examples.

   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “`nix run` - run a Nix application”
   • [claimed-docs] “Remote builds.”
   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”
   • [community] “We're using Nix where I work... it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two…”

   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)
   Nix✓fullprobed8/10

   Nix ships an extensive, well-documented official CLI (nix-shell, nix develop, nix build, nix run, nix search, flake commands) that is fully scriptable and thus usable by AI agents for automation. missing for 10: explicit documentation or examples of AI-agent/automated tool usage of the CLI, independent hands-on corroboration of agentic use cases.

   • [claimed-docs] “the command `nix-shell` will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell in w…”
   • [claimed-docs] “`nix develop` - run a bash shell that provides the build environment of a derivation”
   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “`nix search` - search for packages”
   • [claimed-docs] “`nix run` - run a Nix application”
   • [claimed-docs] “Create a new flake: # nix flake new hello”
   • [probe] “official CLI documented at https://nix.dev/manual/nix/2.28/command-ref/new-cli/nix”

   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)
   Nix—none0/10

   Nix exposes a CLI (nix-shell, nix develop, nix build, etc.) but the evidence pack shows no documented public API, OpenAPI spec, or llms.txt for AI-native programmatic access — probes confirm 404s for openapi.json, llms.txt, and markdown docs endpoints.

   • [probe] “PROBE llms.txt: HTTP 404 at https://nix.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://nix.dev.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://nix.dev/openapi.json, https://nix.dev/swagger.json, https://nix.dev/api/openapi.json, https:…”

   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)
   Nix—none0/10

   Nix is a package manager/build system, not an API-serving product, and the probes explicitly confirm no OpenAPI spec or machine-readable API endpoint exists (404s at llms.txt, docs.md, and all openapi candidate paths).

   • [probe] “PROBE llms.txt: HTTP 404 at https://nix.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://nix.dev.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://nix.dev/openapi.json, https://nix.dev/swagger.json, https://nix.dev/api/openapi.json, https:…”

   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 Bun (package manager)
   Nix—none0/10

   Nix's CLI and declarative configuration model could in principle support scripted bulk operations (e.g. applying a system config to many packages at once), but the evidence pack contains no explicit documentation of batch/bulk operation commands, APIs, or AI-agent-oriented automation for acting across many items simultaneously.

   ⚑ 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 Bun (package manager)
   Nix—none0/10

   The evidence pack documents reproducible dev environments, nix-shell/nix develop, and installation solely in terms of macOS/Linux (curl install script, NixOS configuration, Docker images) with no mention of Windows support anywhere; Nix is well known to require WSL for Windows, and no evidence pack item addresses this at all.

   ⚑ 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 drawn
   Nix—none0/10

   The evidence pack contains extensive Nix documentation on installation, package management, rollbacks, and flakes, but nowhere mentions overlays, third-party taps, plugins, or pluggable backends—the actual extensibility mechanisms Nix is known for. Since no evidence in the pack substantiates this capability, it cannot be credited despite the axis being clearly applicable to a package manager/ecosystem like Nix.

   ⚑ 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 drawn
   Nix—none0/10

   Evidence only describes generic public binary caches (nix-docs-36, nix-docs-52) with no mention of pointing at private registries/mirrors or configuring scoped authentication credentials (e.g., access tokens, netrc) for substituters. missing for 10: documentation of private/self-hosted binary cache configuration, scoped authentication tokens, mirror substitution, and any independent confirmation of enterprise private-registry usage.

   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [claimed-docs] “Transparent build caching using binary caches”

   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 Nix
   Nix✓fullcommunity9/10

   Nixpkgs is documented as offering over 140,000 packages with active maintenance, easy installation via nix-env/nix-shell/nix profile, and community testimony confirms real-world reliance on it for build environments and dependency resolution. Minor gap: no explicit third-party stats on update cadence/registry freshness beyond the package count claim. missing for 10: independent verification of repository update frequency/maintenance activity.

   • [claimed-docs] “Choose from over 140 000 Packages”
   • [claimed-docs] “Nix is extremely useful for developers as it makes it easy to automatically set up the build environment for a package.”
   • [claimed-docs] “the command `nix-shell` will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell in w…”
   • [community] “Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously... It is fast…”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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
   Nix✓fullcommunity8/10

   nix-shell/nix develop and flakes (nix build/nix run) let a developer clone a repo and get a fully declared build/dev environment with one command, backed by community testimony of reliability at scale. missing for 10: a concrete one-command 'clone and go' walkthrough example and independent benchmark of reproducibility across machines beyond anecdote.

   • [claimed-docs] “the command `nix-shell` will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell in w…”
   • [claimed-docs] “`nix develop` - run a bash shell that provides the build environment of a derivation”
   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “Create a new flake: # nix flake new hello”
   • [community] “We're using Nix where I work... it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two…”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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)
   Nix—none0/10

   The evidence pack covers Nix's general reproducibility, rollback, and CLI features but never mentions flake.lock, lockfile verification, or a frozen/immutable install mode that fails when the manifest and lock disagree. Missing for 10: any mention of flake.lock, --no-update-lock-file / frozen-mode flags, or CI enforcement of lockfile consistency.

   ⚑ 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)
   Nix~partialcommunity6/10

   Nix's docs emphasize reproducible development environments, binary caching, and flake-based builds (`nix build`, `nix flake new`) which resolve to pinned versions, and community reports (nix-comm-9) confirm shared, reproducible builds across dev teams. However, the pack never explicitly names or describes the flake.lock lockfile mechanism, its pinning/versioning semantics, or cross-machine lockfile-driven install verification. Missing for 10: explicit flake.lock documentation, evidence of lockfile diffing/version pinning behavior, and independent confirmation that lockfile-based installs reproduce identical resolved versions across machines.

   • [claimed-docs] “Reproducible development environments.”
   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “Create a new flake: # nix flake new hello”
   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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)
   Nix✓fullcommunity8/10

   Nix's design explicitly supports reproducible, per-project environments via nix-shell/nix develop/flakes that pin exact dependency versions and build environments, and community reports confirm this works reliably at scale (nix-comm-6, nix-comm-7, nix-comm-9) with multiple package versions coexisting without conflict (nix-docs-5, nix-docs-49). Docs also confirm atomic, non-overwriting installs and easy environment transfer/reproduction (nix-docs-50, nix-docs-53, nix-docs-42). Missing for 10: explicit mention of flake.lock version pinning mechanics or nixpkgs commit pinning workflow, and independent verification of pin-respecting behavior across upgrades.

   • [claimed-docs] “Reproducible development environments.”
   • [claimed-docs] “You can have multiple versions or variants of a package installed at the same time.”
   • [claimed-docs] “Reproducible development environments”
   • [claimed-docs] “You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications…”
   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “Create a new flake: # nix flake new hello”
   • [claimed-docs] “the command `nix-shell` will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell in w…”
   • [claimed-docs] “`nix develop` - run a bash shell that provides the build environment of a derivation”
   • [community] “Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously... It is fast…”
   • [community] “We're using Nix where I work... it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two…”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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)
   Nix—none0/10

   Nix's documentation describes its own distinct command set (nix-env, nix-shell, nix develop, flakes) with no mention of compatibility shims or command aliases mimicking incumbent package managers (apt, brew, npm, etc.). Community evidence even points the other way, describing real migration friction ('cost of wrapping packages is just a little too high', 'pretty annoying when something doesn't work... have to dig deep') rather than a smooth familiar-command transition.

   • [claimed-docs] “$ nix-env --upgrade --attr nixpkgs.some-package $ nix-env --rollback”
   • [claimed-docs] “the command nix-shell will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell”
   • [claimed-docs] “nix develop - run a bash shell that provides the build environment of a derivation”
   • [community] “I really want to adopt Nix and NixOS for my systems but the cost of wrapping packages is just a little too high for me right now.”
   • [community] “We're doing a project right now to try to migrate to using nix for our python code that runs on a raspberry pi. It's been great in many area…”

   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)
   Nix—none0/10

   The evidence pack shows general Nix package/environment management docs but no documented import or conversion tooling for migrating from another package manager (e.g., npm, pip, conda, Homebrew) into Nix. One community comment mentions attempting to migrate Python code to Nix but describes friction, not an official conversion tool.

   • [community] “We're doing a project right now to try to migrate to using nix for our python code that runs on a raspberry pi. It's been great in many area…”

   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

Workspaces

1. developerManage many packages in one monorepo with workspaces sharing a single lockfile and cross-linked local dependencies

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

   The evidence pack covers Nix's environment reproducibility, package management, rollbacks, and CLI features, but contains no mention of monorepo workspace support, shared lockfiles across multiple packages, or cross-linked local dependency mechanisms akin to npm/yarn/pnpm workspaces. While Nix flakes could conceivably be used to structure a monorepo, no documentation or community evidence describes such a workspace feature.

   ⚑ flag

   Bun (package manager)✓fullcommunity8/10

   Bun's docs thoroughly describe monorepo workspaces with a single shared lockfile (bun.lock), cross-linked local packages, catalogs for shared versions, --filter for scoping installs, and hoisting-barrier controls for self-contained workspaces. Community evidence corroborates reliability gains for monorepo installs (isolated installs), though some users report install bugs and open questions about per-package script execution. Missing for 10: independent large-scale case study of cross-linked local dependency workflows and resolution of the unanswered community question about running scripts on specific workspace packages.

   • [claimed-docs] “With workspaces, you develop several independent packages in a single repository, a _monorepo_.”
   • [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
   • [claimed-docs] “Mark such a workspace as self-contained... For that workspace `bun install` then behaves as a hoisting barrier”
   • [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.”
   • [claimed-docs] “Mark such a workspace as self-contained... nothing it depends on... is placed above `apps/desktop/node_modules`, so that directory is a comp…”
   • [claimed-docs] “Bun supports [`workspaces`](https://docs.npmjs.com/cli/v9/using-npm/workspaces?v=true#description) in `package.json`. With workspaces, you d…”
   • [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
   • [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
   • [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

2. developerRun installs and scripts filtered to a subset of workspace packages (including only those affected by a change)

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

   Nix documentation covers building individual flake outputs (e.g. `nix build`, `nix run`) but there is no evidence of any monorepo/workspace concept, dependency-graph-based 'affected package' detection, or a mechanism to scope installs/scripts to a subset of interdependent packages changed in a diff.

   • [claimed-docs] “Build the flake in the current directory: console # nix build # ./result/bin/hello Hello, world! ”
   • [claimed-docs] “`nix run` - run a Nix application”
   • [claimed-docs] “Create a new flake: # nix flake new hello”

   proof ↗⚑ flag

   Bun (package manager)~partialcommunity6/10

   Bun's docs explicitly support installing (and by extension running) commands scoped to a subset of workspace packages via the `--filter` flag, including glob patterns like `pkg-*` excluding `pkg-c`, or a single package path (bun-docs-32, bun-docs-9, bun-docs-21). However, there is no documented mechanism for detecting packages 'affected by a change' (e.g., git-diff-based filtering as in Turborepo/Nx), and a community comment expresses uncertainty about whether running scripts on specific packages in a monorepo works reliably (bun-comm-10). Missing for 10: change-affected/git-diff-based filtering, explicit script-running (not just install) filter examples, and independent hands-on confirmation.

   • [claimed-docs] “In a monorepo, you can install the dependencies for a subset of packages using the `--filter` flag.”
   • [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
   • [claimed-docs] “Install dependencies for only `pkg-a` in `./packages/pkg-a`”
   • [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 drawn
   Nix—none0/10

   The evidence pack contains only usage/CLI documentation and community discussion about Nix's package management features; none of the citations reference the project's source repository, license, or any open-source licensing statement, so there is no evidence to support this openness story.

   ⚑ 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)
   Nix—none0/10

   The evidence pack contains only qualitative feature descriptions (binary caches, remote builds, atomic operations) and anecdotal community comments about speed/hassle, but no published benchmark numbers, performance metrics, or measured comparisons backing speed claims.

   ⚑ 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 Nix
   Nix✓fullcommunity9/10

   Nix docs explicitly describe automatically skipping source builds in favor of downloading from a binary cache, and this is reinforced by mentions of 'transparent build caching using binary caches'; community testimony corroborates shared build caching saving dev time across teams. Missing for 10: independent hands-on benchmark specifically timing cache-hit vs source-build installs.

   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [claimed-docs] “Transparent build caching using binary caches”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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)
   Nix~partialcommunity5/10

   Nix documents binary caches and remote builds as core caching mechanisms (transparent build caching, automatic binary cache use), and community evidence confirms this yields shared build artifacts across CI/dev/deploy pipelines (nix-comm-9). However, there is no documented CI-specific cache-restore setup (e.g., GitHub Actions cache integration) nor explicit guidance on offline-capable installs. Missing for 10: CI-platform cache-restore tooling/docs, explicit offline-install workflow documentation, and independent CI benchmarking evidence.

   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [claimed-docs] “Transparent build caching using binary caches”
   • [claimed-docs] “Remote builds.”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   proof ↗⚑ 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)
   Nix✓fullcommunity8/10

   Docs describe the Nix store's atomicity ("package management operations never overwrite... just add new versions in different paths"), ability to have multiple versions/variants installed simultaneously, binary caching to avoid rebuilding, and garbage collection of unused store paths — all consistent with a single shared, deduplicated on-disk store. Community evidence corroborates real-world sharing across a dev team: "Everything is only built once... then shared among all of our devs, CI, and deployment infrastructure." missing for 10: explicit documentation of the hash-based content-addressing mechanism itself and independent verification of cross-project dedup at scale.

   • [claimed-docs] “You can have multiple versions or variants of a package installed at the same time.”
   • [claimed-docs] “You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications…”
   • [claimed-docs] “Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are atomic.”
   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”
   • [claimed-docs] “Transparent build caching using binary caches”
   • [claimed-docs] “unused packages can be deleted safely by running the _garbage collector_”
   • [claimed-docs] “unused packages can be deleted safely by running the garbage collector”
   • [community] “I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of speci…”

   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

Auditing

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

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

   No evidence of any vulnerability scanning or CVE auditing capability in Nix's CLI; documentation covers reproducibility, rollbacks, garbage collection, and package installation but nothing about security vulnerability auditing.

   ⚑ 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)
   Nix—none0/10

   No evidence in the pack mentions security controls like blocking lifecycle scripts, minimum package release age enforcement, or any supply-chain malicious-package protections; the pack only covers reproducibility, rollbacks, environments, and installation. missing for 10: any mention of lifecycle-script blocking, minimum release age policy, or malicious package vetting controls.

   ⚑ 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 drawn
   Nix—none0/10

   The evidence pack contains no mention of checksum/signature/attestation verification, binary cache trust settings (e.g., trusted-public-keys), or signed narinfo verification, despite Nix actually supporting such features in reality — none of that is documented in this evidence pack. Binary caches are mentioned only as a performance/caching feature, not as a verified/trusted source.

   • [claimed-docs] “Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries.”

   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 Nix
   Nix✓fullcommunity8/10

   Nix's flakes/nix develop and nix-shell provide per-project, checked-in (flake.nix/shell.nix) reproducible environments that pin exact language/tool versions and let devs switch environments per directory, corroborated by community reports of using nix-shell/flakes for dependency isolation across projects. missing for 10: no explicit direnv/.envrc auto-switch example, and no independent hands-on account specifically describing multi-project runtime version switching via checked-in config.

   • [claimed-docs] “`nix develop` - run a bash shell that provides the build environment of a derivation”
   • [claimed-docs] “nix develop - run a bash shell that provides the build environment of a derivation”
   • [claimed-docs] “the command `nix-shell` will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell in w…”
   • [claimed-docs] “the command nix-shell will build or download those dependencies if they’re not already in your Nix store, and then start a Bash shell”
   • [claimed-docs] “Reproducible development environments”
   • [claimed-docs] “You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications…”
   • [community] “We're using Nix where I work... it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two…”
   • [community] “Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously... It is fast…”

   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