CodeVetter · Repo Unpack · Behavior traces
pnpm/pnpm
Three principal flows were followed through source: CLI startup, dependency installation through installed-state persistence, and pnpr metadata/tarball reads through authorization and cache handling. Additional startup reading distinguishes pnpr's production server API from convenience router construction. The traces retain early returns and policy branches because those determine which work actually occurs. These are execution paths inferred directly from code structure, not observed runs.
- Rust startup follows bin::main → pnpm_cli::main → run_on_big_stack(run_cli) → shim dispatch → argument normalization → parse_or_answer → configure_cli_args → pinned dispatch/completion checks → Rayon setup → install fast-path check → run_cli_command.
- TypeScript startup follows buildArgv → runPnpm → main → parseCliArgs → loadCommandConfig/readCommandConfig → package-manager/runtime handling → config-dependency and hook loading → runCommandWithConfig; runPnpm finally drains workers.
- InstallArgs::run calls run_inner, resolves frozen/link options, rejects pnpr plus dry-run, and selects install_via_pnpr_inner when pnpr_target exists; otherwise run_local builds State::install and invokes run or run_selected.
- Local Install::run → run_inner acquires a store-use lock → run_inner_impl settles RunMode and discovers the workspace → RunExecution::run checks reuse, loads lockfiles, and settles wanted state → dispatch chooses frozen/fresh → materialize → finish_materialization.
- Persistence follows finish_materialization → apply_materialization_result → apply → link_apply_projects → commit_apply_state → finish_apply. commit_modules_state writes module metadata before the current lockfile; finish_apply subsequently publishes workspace freshness and completion output.
- pnpr startup follows Args::parse → Config::resolve_with_overrides → apply_cli_overrides → logging → serve. serve validates configuration, loads active OSV, calls load_startup_auth with registry journal recovery, builds routes, binds the listener, and enters graceful serving.
- A metadata read follows serve_packument → addressed_registry → serve_registry_packument → canonical-name parsing/source selection/access authorization → serve_packument_via_upstream → load_upstream_packument. A fresh cache hit returns immediately; misses fetch and cache, authoritative 404s purge cached package state, and packument_response shapes the client response.
- An upstream tarball read follows serve_registry_tarball → access authorization → serve_tarball_via_upstream → filename validation/authorized_upstream → serve_authorized_upstream_tarball. Without OSV, a cache hit can precede metadata binding; misses bind version/integrity, screen OSV, fetch, open temporary storage, and stream with integrity-gated cache promotion.