docs: update documentation for Bun v1.3.2 features#24503
Conversation
|
Updated 6:14 PM PT - Nov 10th, 2025
✅ @lydiahallie, your commit e274a102225503caf9035dd69a97b40ffc3f3959 passed in 🧪 To try this PR locally: bunx bun-pr 24503That installs a local version of the PR into your bun-24503 --bun |
WalkthroughDocumentation updates: installer/linker defaults and GitHub tarball note; CLI aliases and postinstall flags; new ServerWebSocket.subscriptions API docs; added onTestFinished lifecycle hook; and CPU profiling guidance in benchmarking docs. Changes
Possibly related PRs
Suggested reviewers
Pre-merge checks✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
🧰 Additional context used🧠 Learnings (11)📓 Common learnings📚 Learning: 2025-10-19T02:44:46.354ZApplied to files:
📚 Learning: 2025-08-30T00:12:56.803ZApplied to files:
📚 Learning: 2025-10-19T02:52:37.412ZApplied to files:
📚 Learning: 2025-08-30T00:12:56.803ZApplied to files:
📚 Learning: 2025-10-08T03:11:45.286ZApplied to files:
📚 Learning: 2025-10-26T01:32:04.844ZApplied to files:
📚 Learning: 2025-10-04T09:52:49.414ZApplied to files:
📚 Learning: 2025-10-04T09:52:49.414ZApplied to files:
📚 Learning: 2025-10-08T03:11:45.286ZApplied to files:
📚 Learning: 2025-08-30T00:12:56.803ZApplied to files:
🔇 Additional comments (4)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📥 Commits
Reviewing files that changed from the base of the PR and between fd107468934356666c7b02651e9288bf2eac7adf and c89926f9880078c11819ee9bc66505dc7949db99.
📒 Files selected for processing (2)
docs/pm/isolated-installs.mdx(1 hunks)docs/test/lifecycle.mdx(1 hunks)
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: src/bun.js/bindings/v8/CLAUDE.md:0-0
Timestamp: 2025-09-08T00:41:12.052Z
Learning: Follow existing patterns in similar V8 classes, add comprehensive Node.js parity tests, update all symbol files, and document any special behavior
📚 Learning: 2025-10-19T04:55:33.099Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: test/js/bun/http/node-telemetry.test.ts:27-203
Timestamp: 2025-10-19T04:55:33.099Z
Learning: In test/js/bun/http/node-telemetry.test.ts and the Bun.telemetry._node_binding API, after the architecture refactor, the _node_binding interface only contains two methods: handleIncomingRequest(req, res) and handleWriteHead(res, statusCode). The handleRequestFinish hook and other lifecycle hooks were removed during simplification. Both current methods are fully tested.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-09-20T03:39:41.770Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 22534
File: test/regression/issue/21830.fixture.ts:14-63
Timestamp: 2025-09-20T03:39:41.770Z
Learning: Bun's test runner supports async describe callbacks, unlike Jest/Vitest where describe callbacks must be synchronous. The syntax `describe("name", async () => { ... })` is valid in Bun.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-10-30T03:48:10.513Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 24063
File: packages/bun-otel/test/context-propagation.test.ts:1-7
Timestamp: 2025-10-30T03:48:10.513Z
Learning: In Bun test files, `using` declarations at the describe block level execute during module load/parsing, not during test execution. This means they acquire and dispose resources before any tests run. For test-scoped resource management, use beforeAll/afterAll hooks instead. The pattern `beforeAll(beforeUsingEchoServer); afterAll(afterUsingEchoServer);` is correct for managing ref-counted test resources like the EchoServer in packages/bun-otel/test/ - the using block pattern should not be used at describe-block level for test resources.
<!-- [/add_learning]
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-08-30T00:12:56.803Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-08-30T00:12:56.803Z
Learning: Applies to test/**/*.{js,ts} : Write tests in JavaScript or TypeScript using Bun’s Jest-style APIs (test, describe, expect) and run with bun test
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-09-20T05:38:31.896Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 22534
File: src/bun.js/test/Order.zig:70-78
Timestamp: 2025-09-20T05:38:31.896Z
Learning: In Bun's test Order.zig, the skip logic for beforeAll and afterAll hooks works by calling setFailureSkipTo at specific times: beforeAll failures skip to the first afterAll (setFailureSkipTo called before afterAll generation), and afterAll failures skip to the end (setFailureSkipTo called after afterAll generation). The timing of these calls relative to group generation determines the correct skip targets.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-10-08T13:48:02.430Z
Learnt from: Jarred-Sumner
Repo: oven-sh/bun PR: 23373
File: test/js/bun/tarball/extract.test.ts:107-111
Timestamp: 2025-10-08T13:48:02.430Z
Learning: In Bun's test runner, use `expect(async () => { await ... }).toThrow()` to assert async rejections. Unlike Jest/Vitest, Bun does not require `await expect(...).rejects.toThrow()` - the async function wrapper with `.toThrow()` is the correct pattern for async error assertions in Bun tests.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-11-06T00:58:23.965Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 24417
File: test/js/bun/spawn/spawn.test.ts:903-918
Timestamp: 2025-11-06T00:58:23.965Z
Learning: In Bun test files, `await using` with spawn() is appropriate for long-running processes that need guaranteed cleanup on scope exit or when explicitly testing disposal behavior. For short-lived processes that exit naturally (e.g., console.log scripts), the pattern `const proc = spawn(...); await proc.exited;` is standard and more common, as evidenced by 24 instances vs 4 `await using` instances in test/js/bun/spawn/spawn.test.ts.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-11-08T04:06:33.198Z
Learnt from: Jarred-Sumner
Repo: oven-sh/bun PR: 24491
File: test/js/bun/transpiler/declare-global.test.ts:17-17
Timestamp: 2025-11-08T04:06:33.198Z
Learning: In Bun test files, `await using` with Bun.spawn() is the preferred pattern for spawned processes regardless of whether they are short-lived or long-running. Do not suggest replacing `await using proc = Bun.spawn(...)` with `const proc = Bun.spawn(...); await proc.exited;`.
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-08-30T00:12:56.803Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-08-30T00:12:56.803Z
Learning: Applies to test/**/*.{js,ts} : Prefer data-driven tests (e.g., test.each) to reduce boilerplate
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-08-30T00:12:56.803Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-08-30T00:12:56.803Z
Learning: Applies to test/cli/**/*.{js,ts} : When testing Bun as a CLI, use spawn with bunExe() and bunEnv from harness, and capture stdout/stderr via pipes
Applied to files:
docs/test/lifecycle.mdx
📚 Learning: 2025-08-30T00:12:56.803Z
Learnt from: CR
Repo: oven-sh/bun PR: 0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-08-30T00:12:56.803Z
Learning: Applies to test/**/*.{js,ts} : Use shared utilities from test/harness.ts where applicable
Applied to files:
docs/test/lifecycle.mdx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Format
🔇 Additional comments (4)
docs/test/lifecycle.mdx (1)
38-76: Overall structure and examples are clear and correct.The new
onTestFinishedsection is well-organized with clear explanation, practical examples, and helpful limitations. The first example effectively demonstrates execution order relative toafterEach, and the second example shows real-world async cleanup use case in a serial test context. The important notes section properly conveys scope and constraints.docs/pm/isolated-installs.mdx (3)
1-9: Clear and accurate positioning of the feature.The introduction clearly explains what isolated installs are and establishes the critical context about default behavior—isolated as default for new workspace projects, with backward compatibility for existing projects. The scope and backward compatibility guarantee are well-communicated upfront.
70-147: Technical sections are accurate and well-organized.The directory structure, resolution algorithm, and comparison table clearly explain how isolated installs differ from hoisted. The advanced features section appropriately covers peer dependencies, backend strategies, and debugging without overcomplicating the documentation.
148-220: Troubleshooting and migration guidance is practical and complete.The troubleshooting section correctly identifies real compatibility pain points and offers reasonable solutions. Migration guides are clear with concrete steps. The "when to use" section helps users choose the appropriate strategy for their use case.
Note on documentation links (lines 218-220): The related documentation links use appropriate markdown syntax. However, cross-link validity should be verified separately as part of documentation build/deployment testing (e.g., to confirm
/pm/workspaces,/pm/lockfile, and/pm/cli/installpages exist in the final documentation).
Add documentation for major features introduced in Bun v1.3.2: ## Package Manager - Document configVersion system and default linker behavior - Clarify "made pre-v1.3.2" for existing project backward compatibility - Add smart postinstall script optimization notes - Document `bun list` alias for `bun pm ls` - Note GitHub dependency HTTP tarball optimization ## Testing - Add `onTestFinished` lifecycle hook to table - Add simple usage example in Per-Scope section ## Performance - Add CPU profiling section with `--cpu-prof` flags - Place after memory usage section for better flow ## Documentation Improvements - Use "/docs/pm/isolated-installs" for all internal references - Simplify config comments to reference detailed docs - Remove unnecessary changes (child-process, websockets, installation) - Make all sections concise and factual 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
robobun
force-pushed
the
claude/docs-bun-v1.3.2-updates
branch
from
7dc9246 to
9429d42
Compare
Add ws.subscriptions to existing pub/sub code example and TypeScript reference instead of creating a separate section.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
docs/test/lifecycle.mdx (2)
3-3: Update frontmatter description to includeonTestFinished.The description still references only the original four hooks despite the new
onTestFinishedhook being documented in the page content. This was flagged in a prior review but appears to have been reverted or not carried forward in the current state.- description: "Learn how to use beforeAll, beforeEach, afterEach, and afterAll lifecycle hooks in Bun tests" + description: "Learn how to use beforeAll, beforeEach, afterEach, afterAll, and onTestFinished lifecycle hooks in Bun tests"
94-109: Add done-style callback example foronTestFinished.The section notes that
onTestFinishedsupports "async and done-style callbacks" (implied by comparison to other hooks), but only the async pattern is shown. A prior review flagged this gap. Add a concise done-style example to fully document both supported patterns.Consider adding this after the async example:
test("cleanup after test", () => { onTestFinished(() => { // runs after all afterEach hooks console.log("test finished"); }); });
+Done-style example:
+
+```ts title="test.ts" icon="/icons/typescript.svg"
+test("done-style callback", () => {
- onTestFinished((done) => {
- setTimeout(() => {
// Perform final cleanupdone();- }, 10);
- });
+});
+```</blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: ASSERTIVE **Plan**: Pro **Disabled knowledge base sources:** - Linear integration is disabled by default for public repositories > You can enable these sources in your CodeRabbit configuration. <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between c89926f9880078c11819ee9bc66505dc7949db99 and 3e8f2ccbc54455b5d747ae0a9a8849f04765db54. </details> <details> <summary>📒 Files selected for processing (8)</summary> * `docs/guides/install/add-git.mdx` (1 hunks) * `docs/pm/cli/install.mdx` (4 hunks) * `docs/pm/cli/pm.mdx` (2 hunks) * `docs/pm/isolated-installs.mdx` (1 hunks) * `docs/project/benchmarking.mdx` (1 hunks) * `docs/runtime/bunfig.mdx` (1 hunks) * `docs/runtime/http/websockets.mdx` (2 hunks) * `docs/test/lifecycle.mdx` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🧠 Learnings (20)</summary> <details> <summary>📚 Learning: 2025-09-12T22:30:48.490Z</summary>Learnt from: RiskyMH
Repo: oven-sh/bun PR: 22613
File: src/cli/package_manager_command.zig:0-0
Timestamp: 2025-09-12T22:30:48.490Z
Learning: Commands likebun infoandbun whoamithat are promoted from pm-only subcommands to top-level commands use manualbun.argvparsing to detect direct invocation vs. pm invocation. This is different from regular commands that should usectx.positionals.**Applied to files:** - `docs/pm/cli/pm.mdx` </details> <details> <summary>📚 Learning: 2025-09-12T22:30:48.490Z</summary>Learnt from: RiskyMH
Repo: oven-sh/bun PR: 22613
File: src/cli/package_manager_command.zig:0-0
Timestamp: 2025-09-12T22:30:48.490Z
Learning: Promoted pm subcommands likebun infoandbun whoamiuse manualbun.argvparsing because they are "standalone commands" that bypass the normal command flow. They parse arguments manually starting from argv[2], skip flags, then delegate to the corresponding pm functionality (e.g.,bun infocallsPmViewCommand.view()). This pattern is different from regular commands that usectx.positionals.**Applied to files:** - `docs/pm/cli/pm.mdx` </details> <details> <summary>📚 Learning: 2025-10-19T04:55:33.099Z</summary>Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: test/js/bun/http/node-telemetry.test.ts:27-203
Timestamp: 2025-10-19T04:55:33.099Z
Learning: In test/js/bun/http/node-telemetry.test.ts and the Bun.telemetry._node_binding API, after the architecture refactor, the _node_binding interface only contains two methods: handleIncomingRequest(req, res) and handleWriteHead(res, statusCode). The handleRequestFinish hook and other lifecycle hooks were removed during simplification. Both current methods are fully tested.**Applied to files:** - `docs/test/lifecycle.mdx` </details> <details> <summary>📚 Learning: 2025-09-20T03:39:41.770Z</summary>Learnt from: pfgithub
Repo: oven-sh/bun PR: 22534
File: test/regression/issue/21830.fixture.ts:14-63
Timestamp: 2025-09-20T03:39:41.770Z
Learning: Bun's test runner supports async describe callbacks, unlike Jest/Vitest where describe callbacks must be synchronous. The syntaxdescribe("name", async () => { ... })is valid in Bun.**Applied to files:** - `docs/test/lifecycle.mdx` </details> <details> <summary>📚 Learning: 2025-10-30T03:48:10.513Z</summary>Learnt from: theshadow27
Repo: oven-sh/bun PR: 24063
File: packages/bun-otel/test/context-propagation.test.ts:1-7
Timestamp: 2025-10-30T03:48:10.513Z
Learning: In Bun test files,usingdeclarations at the describe block level execute during module load/parsing, not during test execution. This means they acquire and dispose resources before any tests run. For test-scoped resource management, use beforeAll/afterAll hooks instead. The patternbeforeAll(beforeUsingEchoServer); afterAll(afterUsingEchoServer);is correct for managing ref-counted test resources like the EchoServer in packages/bun-otel/test/ - the using block pattern should not be used at describe-block level for test resources.
| ## CPU profiling | ||
|
|
||
| Profile JavaScript execution to identify performance bottlenecks with the `--cpu-prof` flag. | ||
|
|
||
| ```sh terminal icon="terminal" | ||
| bun --cpu-prof script.js | ||
| ``` | ||
|
|
||
| This generates a `.cpuprofile` file you can open in Chrome DevTools (Performance tab → Load profile) or VS Code's CPU profiler. | ||
|
|
||
| ### Options | ||
|
|
||
| ```sh terminal icon="terminal" | ||
| bun --cpu-prof --cpu-prof-name my-profile.cpuprofile script.js | ||
| bun --cpu-prof --cpu-prof-dir ./profiles script.js | ||
| ``` | ||
|
|
||
| | Flag | Description | | ||
| | ---------------------------- | -------------------- | | ||
| | `--cpu-prof` | Enable profiling | | ||
| | `--cpu-prof-name <filename>` | Set output filename | | ||
| | `--cpu-prof-dir <dir>` | Set output directory | |
There was a problem hiding this comment.
🧩 Analysis chain
Verify CPU profiling flags and output format for Bun v1.3.2.
The new CPU profiling section is well-structured and clearly documented. However, please verify that the flag names and output format are accurate for Bun v1.3.2.
🏁 Script executed:
#!/bin/bash
# Description: Verify CPU profiling flags exist in Bun
# Check the Bun CLI help for the --cpu-prof flag and related options
bun --help | grep -A 10 "cpu-prof"Length of output: 41
🌐 Web query:
Bun v1.3.2 CPU profiling --cpu-prof flag documentation
💡 Result:
Yes — Bun (v1.3.x) supports V8 CPU profiling via the --cpu-prof flag. Usage and behavior (same basic semantics as Node’s flags):
- Enable CPU sampling: bun --cpu-prof run ./your-app.js. (Starts V8 CPU profiler and writes a .cpuprofile on exit.) (toolstac.com)
- Output file: Bun writes a .cpuprofile file to the working directory by default; you can control directory/name with the same flags Node exposes (e.g., --cpu-prof-dir and --cpu-prof-name). (nodejs.org)
- Sampling interval: the profiler sampling interval can be adjusted with --cpu-prof-interval (interval in microseconds; Node default is 1000 µs). (nodejs.org)
- Related Bun profiling flags: --heap-prof for heap snapshots and --print-stats for runtime stats. (toolstac.com)
If you want exact CLI help on your installed Bun v1.3.2, run: bun --help or bun --version and bun --help | grep prof to see available profiling flags on that binary. (bun.com)
Citations:
- 1: https://toolstac.com/tool/bun/troubleshooting-resources?utm_source=openai
- 2: https://nodejs.org/download/release/v12.10.0/docs/api/cli.html?utm_source=openai
- 3: https://nodejs.org/download/release/v12.10.0/docs/api/cli.html?utm_source=openai
- 4: https://toolstac.com/tool/bun/troubleshooting-resources?utm_source=openai
- 5: https://bun.com/reference?utm_source=openai
🌐 Web query:
Bun official documentation CPU profiling command syntax
💡 Result:
Short answer — Bun supports CPU profiling via the WebKit inspector (use bun's --inspect flags and the DevTools Profiles panel), programmatic console.profile()/console.profileEnd(), and the JavaScriptCore sampling profiler API.
Examples and syntax:
- Start Bun with the inspector (open DevTools → Profiles): bun --inspect <script> (also --inspect-brk, --inspect-wait, or specify port/url). [2]
- Programmatic CPU profile (shows in the inspector Profiles panel):
- console.profile('label'); ... console.profileEnd('label');. [1]
- Start JSC sampling profiler programmatically (writes profiler data): Bun.bun:jsc.startSamplingProfiler(optionalDirectory?). [3]
Sources:
- Console.profile / profileEnd docs. [1]
- Debugger / --inspect docs (bun --inspect / --inspect-brk / --inspect-wait). [2]
- bun:jsc.startSamplingProfiler API. [3]
🌐 Web query:
site:bun.sh CPU profiling documentation
💡 Result:
Bun's CPU-profiling docs on bun.sh:
- console.profile / console.profileEnd — start/stop a JavaScript CPU profile (appears in the inspector Profiles panel). [1][2]
- bun:jsc.startSamplingProfiler — run JavaScriptCore's sampling profiler (can write profiler output to a directory). [3]
- General API reference (search these entries in the Bun reference). [4]
References:
[1] https://bun.sh/reference/globals/Console/profile
[2] https://bun.sh/reference/globals/Console/profileEnd
[3] https://bun.sh/reference/bun/jsc/startSamplingProfiler
[4] https://bun.sh/reference
🌐 Web query:
Bun --cpu-prof flag Node.js compatibility CLI profiling
💡 Result:
Short answer
- Yes — Bun supports a --cpu-prof CLI flag that produces .cpuprofile CPU profile files you can open with tools like speedscope / Chrome DevTools. [1][2]
- The produced .cpuprofile follows the common V8-style/Chrome-compatible profile format used by Node tooling, so existing tooling that reads .cpuprofile (speedscope, DevTools) works. [3][4]
Notes / practical tips
- Run: bun --cpu-prof run your-app.js (or bun --cpu-prof --cpu-prof-dir=/path ...). [1][2]
- Open the generated CPU.*.cpuprofile file in speedscope or Chrome DevTools. [3]
- Behavior differences: Bun uses JavaScriptCore (not V8), so function names/frames or sampling details may differ from Node/V8 profiles even though the file format is consumable; expect small semantic differences in flamegraphs. (Bun docs show the flags; speedscope/DevTools document .cpuprofile support.) [1][3][4]
Sources
- Bun docs / troubleshooting and CLI examples (shows bun --cpu-prof usage). [1]
- Bun API / benchmarking pages describing profiling flags. [2]
- speedscope (reads .cpuprofile files produced by Node/V8). [3]
- Node CLI docs for --cpu-prof / .cpuprofile behavior (format/filenames and options). [4]
🌐 Web query:
Bun "bun --cpu-prof run" exact syntax documentation
💡 Result:
Short answer — Bun accepts the same CPU-profiling style flags at process-start and you run it like:
bun [bun‑flags] --cpu-prof [--cpu-prof-dir
] [--cpu-prof-name ] [--cpu-prof-interval ] run <file|script> [script-args]Examples:
- bun --cpu-prof run index.js
- bun --cpu-prof --cpu-prof-dir=/tmp/profiles run server.js
Notes/sources:
- bun run CLI docs (how to place Bun flags immediately after
bun). [1] - Community / troubleshooting examples showing bun --cpu-prof usage. [2]
- Node.js CLI docs for exact semantics and additional cpu-prof flags (filename, dir, interval) — Bun follows the same flag names/semantics. [3]
Sources:
[1] https://bun.sh/docs/cli/run
[2] https://toolstac.com/tool/bun/troubleshooting-resources
[3] https://nodejs.org/docs/latest-v18.x/api/cli.html#--cpu-prof
If you want, I can fetch the exact file-name pattern Bun produces (and confirm which of the optional cpu-prof-* flags Bun implements) for your current Bun version — tell me your bun --version and I'll look it up.
Fix CPU profiling command syntax—add missing run keyword.
The CPU profiling section has correct flag names and output format, but the command examples are missing the required run keyword. The commands should be:
bun --cpu-prof run script.jsbun --cpu-prof --cpu-prof-name my-profile.cpuprofile run script.js
bun --cpu-prof --cpu-prof-dir ./profiles run script.jsAdditionally, consider documenting the --cpu-prof-interval flag (adjusts sampling interval in microseconds) for completeness, though the three main flags cover basic usage.
🤖 Prompt for AI Agents
In docs/project/benchmarking.mdx around lines 220 to 241, the CPU profiling
command examples are missing the required run keyword; update each example to
include run before the script (e.g., bun --cpu-prof run script.js and bun
--cpu-prof --cpu-prof-name my-profile.cpuprofile run script.js, bun --cpu-prof
--cpu-prof-dir ./profiles run script.js) and optionally add a brief line
documenting the --cpu-prof-interval flag (sampling interval in microseconds)
under the Options section.
Convert line endings from CRLF to LF to match repository standards and prevent unnecessary diffs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
3 participants
Summary
Updates documentation for all major features and changes introduced in Bun v1.3.2 blog post.
Changes
Package Manager
configVersionsystem for controlling default linker behaviorbun listalias forbun pm lsTesting
onTestFinishedlifecycle hook with simple exampleRuntime & Performance
--cpu-profflag documentationWebSockets
subscriptionsgetter to existing pub/sub exampleDocumentation Improvements
All documentation now consistently:
/docs/pm/isolated-installs/docs/pm/isolated-installsfor all internal referencesFiles Modified
docs/guides/install/add-git.mdx- Added GitHub tarball optimization notedocs/pm/cli/install.mdx- Added installation strategies and smart postinstall docsdocs/pm/cli/pm.mdx- Added bun list aliasdocs/pm/isolated-installs.mdx- Updated default behavior section with configVersion tabledocs/project/benchmarking.mdx- Added CPU profiling sectiondocs/runtime/bunfig.mdx- Clarified install.linker defaultsdocs/runtime/http/websockets.mdx- Added subscriptions to example and TypeScript interfacedocs/test/lifecycle.mdx- Added onTestFinished hook documentationDiff
🤖 Generated with Claude Code