Incredibly fast JavaScript runtime, bundler, test runner, and package manager โ all in one
by oven-sh5 of 6 standards met
This is a tracking issue for commands that we should implement as builtins in the Bun shell. Some of these are taken from GNU coreutils. [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] [x] [x] [ ] [x] [ ] [ ] [ ] [ ] [ ] [ ] [x] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] This is not an exhaustive list, we can add commands as we think it's a good idea to implement. While these will already be generally available on most posix systems, having them in the Shell will also allow them to be readily available on Windows when using Bun Shell.
Repository: oven-sh/bun. Description: Incredibly fast JavaScript runtime, bundler, test runner, and package manager โ all in one Stars: 87730, Forks: 4113. Primary language: Zig. Languages: Zig (60.6%), C++ (24.7%), TypeScript (8.3%), C (3.3%), JavaScript (1.5%). Homepage: https://bun.com Topics: bun, bundler, javascript, javascriptcore, jsx, nodejs, npm, react, transpiler, typescript, zig, ziglang. Latest release: bun-v1.3.10 (2d ago). Open PRs: 100, open issues: 5981. Last activity: 1h ago. Community health: 100%. Top contributors: Jarred-Sumner, dylan-conway, nektro, robobun, paperclover, cirospaciari, Electroid, colinhacks, pfgithub, alexlamsl and others.
Zig
Last 12 weeks ยท 460 commits
Summary Fixes / client response streams hanging under high concurrency when responses have delayed chunks (e.g. AWS SDK S3 downloads) Adds proper backpressure handling to โ pauses reading from the ReadableStream when the Node.js Readable buffer is full, resumes when is called Avoids calling on normal stream completion (uses instead) Test plan [x] New regression test: โ 20 workers ร 50 iterations with chunked delayed responses [x] Verified regression test times out (hangs) with system bun, passes with fix [x] Original reproduction script (50 workers ร 200 iterations = 10,000 requests) completes all downloads with fix [x] โ 77 pass (1 pre-existing proxy failure) [x] โ 3 pass [x] โ 2 pass Closes #27557 ๐ค Generated with Claude Code
Summary Fix in the REPL to properly handle multi-line content recalled from history by tracking rendered lines, clearing them before redraw, and correctly positioning the cursor Fix history file persistence so multi-line entries aren't corrupted across sessions (uses ASCII Record Separator delimiter with backward compatibility for legacy files) Closes #27560 What was the bug? When multi-line code (e.g., ) was entered in the REPL and then recalled via the up arrow key, each keystroke (backspace, cursor movement, etc.) caused the entire multi-line content to be reprinted on screen, creating duplicated output that grew with each keypress. Root cause: only cleared one terminal line () before redrawing, but the buffer from multi-line history entries contained embedded characters that spanned multiple terminal lines. Each redraw would output new lines below without clearing the previous rendering. Secondary issue: The history file used as both the entry delimiter and internal line separator, so multi-line entries were fragmented into separate entries when saved and reloaded. Changes : Added multi-line rendering path that moves cursor up to clear previously rendered extra lines, writes continuation prompts () for each line, and properly positions the cursor within multi-line content : New helper that moves the cursor past multi-line content before Enter/Ctrl+C so output appears below it /**: Uses ASCII Record Separator () as entry delimiter when multi-line entries exist, with backward compatibility for legacy newline-delimited files : New state field tracking extra terminal lines from the previous render Added regression test for recalling multi-line history and editing it Test plan [x] All 106 existing REPL tests pass [x] New regression test passes with debug build [ ] Manual testing: enter multi-line code in REPL, press up arrow, press backspace โ display should update cleanly without duplicating content ๐ค Generated with Claude Code