Claude Bot 6918a1ee81 Fix code splitting chunk generation to match esbuild behavior
When using code splitting with multiple entry points, Bun was incorrectly
reusing entry point chunks as shared chunks, causing duplicate export
statements when re-exporting symbols between entry points.

Root cause: Entry point chunks were created AFTER markFileReachableForCodeSplitting
had already propagated entry bits to all reachable files. This meant that when
entry point b.ts was imported by entry point a.ts, b.ts would have BOTH bits
{0,1} set at chunk creation time. The chunk key was based on these accumulated
bits, causing the entry point chunk to be reused as a shared chunk.

The fix consists of two changes:

1. computeChunks.zig: Create entry point chunks with ONLY their own entry bit
   When creating entry point chunks, use a bitset containing ONLY the current
   entry point's bit, not the file's accumulated entry_bits. This ensures each
   entry point gets its own chunk, and shared code creates separate chunk files.

   IMPORTANT: Use this.allocator() not temp_allocator for the bitset, since it
   gets stored in the chunk which outlives the temp allocator. For large numbers
   of entry points (> 127), AutoBitSet uses dynamic allocation, and temp_allocator
   would cause use-after-free.

2. P.zig: Always create wrapper_ref symbol during parsing
   Previously, wrapper_ref was only created if needsWrapperRef() returned true
   (file has side effects). But the wrapping decision can be made later during
   linking (e.g., when we discover an ESM file is require'd). This caused
   wrap=.esm but wrapper_ref.isEmpty()=true, breaking code splitting.

   Now we match esbuild's behavior: always create the wrapper symbol during
   parsing when bundling, even if we don't think we need it yet. The linker
   decides whether to actually use it based on flags.wrap.

3. computeCrossChunkDependencies.zig: Remove isEmpty() checks
   Since wrapper_ref now always exists when bundling, we can remove the isEmpty()
   checks. The actual wrapping is still controlled by flags.wrap, so we don't
   generate unnecessary wrappers.

Result:
- Before: b.ts became both the entry point AND contained shared code, with
  duplicate export statements
- After: b.ts entry point imports from a shared chunk file, just like esbuild

This fixes the fundamental chunking strategy to properly separate entry points
from shared chunks.
2025-11-06 11:25:18 +00:00
2025-10-07 20:08:57 -07:00
2025-11-04 13:11:52 -08:00
2025-11-04 17:15:16 -08:00
2025-11-01 19:58:13 -07:00
2024-12-26 11:48:30 -08:00
2024-12-12 03:21:56 -08:00
2025-10-05 04:28:25 -07:00
2025-01-07 20:19:12 -08:00
2025-10-25 21:34:24 -07:00
2025-10-22 12:13:14 -07:00
2024-07-24 01:30:31 -07:00
2025-07-10 00:10:43 -07:00
2025-07-10 00:10:43 -07:00

Logo

Bun

stars Bun speed

Documentation   •   Discord   •   Issues   •   Roadmap

Read the docs →

What is Bun?

Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It ships as a single executable called bun.

At its core is the Bun runtime, a fast JavaScript runtime designed as a drop-in replacement for Node.js. It's written in Zig and powered by JavaScriptCore under the hood, dramatically reducing startup times and memory usage.

bun run index.tsx             # TS and JSX supported out-of-the-box

The bun command-line tool also implements a test runner, script runner, and Node.js-compatible package manager. Instead of 1,000 node_modules for development, you only need bun. Bun's built-in tools are significantly faster than existing options and usable in existing Node.js projects with little to no changes.

bun test                      # run tests
bun run start                 # run the `start` script in `package.json`
bun install <pkg>             # install a package
bunx cowsay 'Hello, world!'   # execute a package

Install

Bun supports Linux (x64 & arm64), macOS (x64 & Apple Silicon) and Windows (x64).

Linux users — Kernel version 5.6 or higher is strongly recommended, but the minimum is 5.1.

x64 users — if you see "illegal instruction" or similar errors, check our CPU requirements

# with install script (recommended)
curl -fsSL https://bun.com/install | bash

# on windows
powershell -c "irm bun.com/install.ps1 | iex"

# with npm
npm install -g bun

# with Homebrew
brew tap oven-sh/bun
brew install bun

# with Docker
docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Upgrade

To upgrade to the latest version of Bun, run:

bun upgrade

Bun automatically releases a canary build on every commit to main. To upgrade to the latest canary build, run:

bun upgrade --canary

View canary build

Guides

Contributing

Refer to the Project > Contributing guide to start contributing to Bun.

License

Refer to the Project > License page for information about Bun's licensing.

Description
Bun is a fast, incrementally adoptable all-in-one JavaScript, TypeScript & JSX toolkit. Use individual tools like bun test or bun install in Node.js projects, or adopt the complete stack with a fast JavaScript runtime, bundler, test runner, and package manager built in. Bun aims for 100% Node.js compatibility.
Readme 680 MiB
Languages
Zig 60.5%
C++ 24.9%
TypeScript 8.3%
C 3.3%
JavaScript 1.4%
Other 1.1%