# Data flow — oven-sh/bun

> Canonical page: https://codevetter.com/unpack/bun/data-flow

# Data flow — oven-sh/bun

Scanned commit bf80d21c69c355f6e5bae2749485674663ed13a1 (2026-09-22). Generated by codevetter codevetter 1.12.0 on 2026-09-22.

Three main pipelines dominate. (1) Source → runtime: the JSC module loader asks `Bun__transpile*` hooks in `jsc_hooks.rs`, which resolve through `bun_resolver`, parse with `bun_js_parser`, print with `bun_js_printer`, and hand a `ResolvedSource` back to JSC; results are cached in a `RuntimeTranspilerStore` and an arena that is reset between graphs. (2) Package manifests → lockfile → disk: `install_with_manager` loads the lockfile, resolves dependencies via the registry client and task queue, runs a security scan, extracts tarballs, links binaries, then runs lifecycle scripts and saves the lockfile. (3) Bundling: `BundleV2` owns a `Graph` of parse tasks fanned out to worker threads, then `LinkerContext` performs tree-shaking, chunking, and sourcemap emission. Cross-thread movement is explicit: `ConcurrentTask`/`DeferredTaskQueue` marshal work onto the JS thread, and the HTTP client runs on its own `HTTPThread`.
- Module loading is split across the crate boundary on purpose: `ModuleLoader` and `FetchFlags` live in `bun_jsc`, while the actual `transpile_source_code`/`fetch_builtin_module` bodies and the `Bun__transpile*`/`Bun__resolve*` C++ entry points live in `bun_runtime::jsc_hooks` and are reached through link-time `extern "Rust"` declarations. — [src/jsc/ModuleLoader.rs#L1-20](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/jsc/ModuleLoader.rs#L1-L20) [src/runtime/jsc_hooks.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/jsc_hooks.rs)
- The transpiler arena is owned by `ModuleLoader::transpile_source_code_arena` and reset between module graphs via `ModuleLoader::reset_arena`, which takes `&mut VirtualMachine` rather than `&mut self` because `ModuleLoader` is a value field of the VM and taking both would alias. — [src/jsc/ModuleLoader.rs#L48-70](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/jsc/ModuleLoader.rs#L48-L70)
- Entry-point evaluation flows `vm.load_entry_point(entry)` → a JSC internal promise; a rejected promise is routed to `vm.uncaught_exception` with an `is_rejection` flag derived from `entry_point_result.evaluated_as_cjs`, so a CJS entry's top-level throw is reported as `uncaughtException` and an ESM entry's as `unhandledRejection`, matching Node. — [src/runtime/cli/run_command.rs#L1424-1455](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/cli/run_command.rs#L1424-L1455) [src/jsc/VirtualMachine.rs#L68-78](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/jsc/VirtualMachine.rs#L68-L78)
- Environment data enters through `bun_dotenv::Loader` wired onto the transpiler, is published to the HTTP client via `bun_http::async_http::load_env`, and on Windows the UTF-16 OS environment block is converted to WTF-8 in `main()` before anything reads `process.env`. — [src/runtime/cli/run_command.rs#L1203-1210](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/cli/run_command.rs#L1203-L1210) [src/runtime/bin_entry/mod.rs#L184-192](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/bin_entry/mod.rs#L184-L192)
- CLI configuration merges three inputs — argv (parsed by `Arguments::parse` into a `ContextData`), the `BUN_OPTIONS` env var (spliced into argv), and `bunfig.toml` parsed by `src/bunfig/bunfig.rs` — with `ctx.args`/`ctx.debug`/`ctx.runtime_options` as the state owner passed down to every command. — [src/runtime/cli/mod.rs#L1276-1284](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/cli/mod.rs#L1276-L1284) [src/runtime/cli/mod.rs#L1345-1380](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/cli/mod.rs#L1345-L1380) [src/bunfig/bunfig.rs#L1177-1260](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/bunfig/bunfig.rs#L1177-L1260)
- Registry credentials flow from two sources into one `api::NpmRegistry` value: `.npmrc`-style `_authToken` segments parsed in `src/install/npm.rs`, and `[install.scopes]` entries in bunfig where explicit `username`/`password`/`token` keys replace any credentials embedded in the URL as a set. — [src/install/npm.rs#L390-440](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/npm.rs#L390-L440) [src/bunfig/bunfig.rs#L1193-1240](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/bunfig/bunfig.rs#L1193-L1240)
- `install_with_manager` is the state machine for installs: prefetch DNS for the registry, load the lockfile from cwd, reconcile config version, diff the root package, enqueue dependency resolution, run tasks, then save the lockfile — with a `mark_loaded_packages()` checkpoint so packages appended by manifest fetches are distinguishable from lockfile pins. — [src/install/PackageManager/install_with_manager.rs#L50-120](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/PackageManager/install_with_manager.rs#L50-L120) [src/install/PackageManager/runTasks.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/PackageManager/runTasks.rs)
- The security scanner runs user-supplied scanning code out-of-process and talks to it over two dedicated file descriptors — fd 3 for the child's JSON result and fd 4 for the parent's package list, read to EOF — rather than stdin/stdout, so scanner console output can't corrupt the protocol. — [src/install/PackageManager/scanner-entry.ts#L1-40](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/PackageManager/scanner-entry.ts#L1-L40) [src/install/PackageManager/security_scanner.rs#L50-70](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/PackageManager/security_scanner.rs#L50-L70)
- Lifecycle scripts are spawned through `bun_spawn` from `src/install/lifecycle_script_runner.rs`, which is deliberately placed in the lower `bun_install` crate so `bun run` and package-install script execution share one implementation (`RunCommand::replace_package_manager_run` is a thin re-export). — [src/install/lifecycle_script_runner.rs#L32-46](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/install/lifecycle_script_runner.rs#L32-L46)
- Bundling state is owned by `BundleV2`, which holds a `Graph`, a `PathToSourceIndexMap`, `ParseTask`s, and an optional second `ssr_transpiler` used for the client half of a Server Components build; linking and chunking happen in the separate `LinkerContext`. — [src/bundler/bundle_v2.rs#L55-75](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/bundler/bundle_v2.rs#L55-L75) [src/bundler/LinkerContext.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/bundler/LinkerContext.rs) [src/bundler/Graph.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/bundler/Graph.rs)
- The dev server keeps every build artifact in memory behind an `IncrementalGraph` with the stated invariant that editing a file must rebundle exactly that file, and exposes a `memory_cost_detailed` breakdown so that in-memory retention is measurable. — [src/runtime/bake/DevServer.rs#L1-10](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/bake/DevServer.rs#L1-L10) [src/runtime/bake/DevServer.rs#L56-62](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/bake/DevServer.rs#L56-L62) [src/runtime/bake/dev_server/incremental_graph.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/bake/dev_server/incremental_graph.rs)
- Cross-thread data movement is centralized in `src/event_loop/`: `ConcurrentTask` and `DeferredTaskQueue` enqueue onto the JS thread, `AnyEventLoop` abstracts over the uWS loop on POSIX and libuv on Windows, and `MiniEventLoop`/`SpawnSyncEventLoop` serve non-JS contexts like the package manager. — [src/event_loop/lib.rs#L1-25](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/event_loop/lib.rs#L1-L25) [src/event_loop/ConcurrentTask.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/event_loop/ConcurrentTask.rs) [src/event_loop/AnyEventLoop.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/event_loop/AnyEventLoop.rs)
- Outbound HTTP is a separate subsystem with its own thread and protocol clients — `HTTPThread.rs`, `H2Client.rs` (HTTP/2 over lshpack), `H3Client.rs` (HTTP/3 over lsquic), plus decompression and certificate-info paths — and `fetch` opts into h2/h3 via process-global atomics set from CLI flags. — [src/http/lib.rs#L1-30](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/http/lib.rs#L1-L30) [src/runtime/cli/run_command.rs#L1211-1220](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/cli/run_command.rs#L1211-L1220)
- S3 requests are signed in the `bun_s3_signing` crate, which owns credentials, ACL, storage class, and multipart options as pure config with no JSC dependency, and the runtime's `S3Client`/`S3File` re-export it — keeping signing testable below the JS tier. — [src/s3_signing/credentials.rs#L1-55](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/s3_signing/credentials.rs#L1-L55) [src/runtime/webcore/S3Client.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/webcore/S3Client.rs) [src/runtime/webcore/S3File.rs](https://github.com/oven-sh/bun/blob/bf80d21c69c355f6e5bae2749485674663ed13a1/src/runtime/webcore/S3File.rs)

Every claim links to its cited files at the pinned commit. Citations identify source evidence; they do not establish runtime correctness. Independent CodeVetter scan — not reviewed by upstream maintainers.

## Public product links

- [CodeVetter](https://codevetter.com/)
- [Download](https://codevetter.com/download)
- [Documentation](https://codevetter.com/docs/)
- [Source](https://github.com/Codevetter/codevetter)