-
Couldn't load subscription status.
- Fork 3.5k
docs: Add v1.2.22 feature documentation #23108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Add async stack traces documentation to debugger docs - Document structuredClone performance optimizations - Add bundler minification optimization details - Document perf_hooks.monitorEventLoopDelay implementation - Add http.Server.closeIdleConnections documentation - Document interactive TTY support after stdin closes - Add WebSocket subprotocol negotiation documentation - Document WebSocket header override capabilities - Add Redis hget() method documentation - Document bun run --workspaces flag 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
WalkthroughThis PR updates documentation only: adds examples for Redis hash retrieval, expands WebSocket client sections (subprotocols and custom headers), introduces Bundler minification optimization notes, documents bun run --workspaces, adds an async stack traces section to the debugger docs, and updates Node.js API support/notes. Changes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests
🧪 Early access (Sonnet 4.5): enabledWe are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience. Note:
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/runtime/nodejs-apis.md (2)
43-43: Consider removing redundant mention ofcloseIdleConnections().Since
node:httpis marked as "🟢 Fully implemented," explicitly calling out thatcloseIdleConnections()is implemented creates redundancy. If the intent is to highlight a recent addition, consider rephrasing to make that clearer (e.g., "Recently added:closeIdleConnections()"). Otherwise, the callout is unnecessary.
83-83: Clarify "interactive TTY support after stdin closes."The phrase "after stdin closes" may be unclear to readers. Consider adding a brief explanation of what scenario this addresses or when this capability is relevant.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (6)
docs/api/redis.md(1 hunks)docs/api/websockets.md(1 hunks)docs/bundler/index.md(1 hunks)docs/cli/run.md(1 hunks)docs/runtime/debugger.md(1 hunks)docs/runtime/nodejs-apis.md(4 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-09-20T03:39:41.770Z
Learnt from: pfgithub
PR: oven-sh/bun#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/runtime/debugger.md
📚 Learning: 2025-09-02T05:33:37.517Z
Learnt from: Jarred-Sumner
PR: oven-sh/bun#22323
File: test/js/web/websocket/websocket-subprotocol.test.ts:74-75
Timestamp: 2025-09-02T05:33:37.517Z
Learning: In Bun's runtime, `await using` with Node.js APIs like `net.createServer()` is properly supported and should not be replaced with explicit cleanup. Bun has extended Node.js APIs with proper async dispose support.
Applied to files:
docs/runtime/debugger.md
📚 Learning: 2025-08-30T00:13:36.815Z
Learnt from: CR
PR: oven-sh/bun#0
File: .cursor/rules/zig-javascriptcore-classes.mdc:0-0
Timestamp: 2025-08-30T00:13:36.815Z
Learning: Applies to src/bun.js/**/*.zig : Access JS call data via CallFrame (argument(i), argumentCount(), thisValue()) and throw errors with globalObject.throw(...)
Applied to files:
docs/runtime/debugger.md
📚 Learning: 2025-08-30T00:12:56.803Z
Learnt from: CR
PR: oven-sh/bun#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/cli/run.md
🪛 Gitleaks (8.28.0)
docs/api/websockets.md
[high] 317-317: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 markdownlint-cli2 (0.18.1)
docs/cli/run.md
174-174: Dollar signs used before commands without showing output
(MD014, commands-show-output)
🔇 Additional comments (7)
docs/api/redis.md (1)
135-137: LGTM!The
hgetexample is clear and well-placed after thehmgetexample, showing a natural progression from retrieving multiple fields to a single field.docs/runtime/debugger.md (1)
326-346: LGTM!The async stack traces documentation is clear and provides a concise example showing how Bun displays the complete async execution path.
docs/cli/run.md (1)
169-177: LGTM!The
--workspacesflag documentation is clear and concise, with a practical example. The behavior (skipping packages without the script) is clearly stated.docs/api/websockets.md (2)
296-307: LGTM!The subprotocol negotiation section clearly demonstrates how to request multiple protocols and access the server's chosen protocol.
309-321: LGTM!The custom headers section clearly explains this Bun-specific extension and provides practical examples for authentication and custom requirements. The static analysis hint about the
Sec-WebSocket-Keyvalue is a false positive—this is a standard example value from the WebSocket specification.docs/bundler/index.md (1)
784-790: LGTM!The minification optimizations subsection provides specific, actionable information about the bundler's minification behavior. The examples are clear and the
--keep-namesreference is consistent with earlier documentation.docs/runtime/nodejs-apis.md (1)
127-127: LGTM!Clear status update reflecting that
monitorEventLoopDelayis now implemented whilecreateHistogramremains missing. The format is consistent with other API status entries.
| ### Performance | ||
|
|
||
| `structuredClone()` uses the same optimized serialization as `postMessage()`. For simple objects containing only primitives, it can be up to 240x faster than standard structured cloning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion | 🟠 Major
Fix heading level and clarify performance claim context.
Two issues with this new section:
-
Structural problem: The
### Performanceheading sits at the same level as API entries (like### structuredClone()), breaking the document structure. Since this note specifically applies tostructuredClone(), either:- Move it as a paragraph under the
structuredClone()entry (lines 405-407), or - Use a sub-heading level (
####) to show it's subordinate tostructuredClone()
- Move it as a paragraph under the
-
Missing context for "240x faster" claim:
- What is "standard structured cloning" being compared against? (Node.js? Spec baseline? Another runtime?)
- What qualifies as "simple objects containing only primitives"?
- Adding this context will help readers understand when they can expect these gains
Apply this diff to fix the structure (Option 1 - integrate as a note):
### [`structuredClone()`](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)
🟢 Fully implemented.
+
+**Performance note:** `structuredClone()` uses the same optimized serialization as `postMessage()`. For simple objects containing only primitives, it can be up to 240x faster than standard structured cloning.
-### Performance
-
-`structuredClone()` uses the same optimized serialization as `postMessage()`. For simple objects containing only primitives, it can be up to 240x faster than standard structured cloning.
-
### [`SubtleCrypto`](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Performance | |
| `structuredClone()` uses the same optimized serialization as `postMessage()`. For simple objects containing only primitives, it can be up to 240x faster than standard structured cloning. | |
| ### [`structuredClone()`](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone) | |
| 🟢 Fully implemented. | |
| **Performance note:** `structuredClone()` uses the same optimized serialization as `postMessage()`. For simple objects containing only primitives, it can be up to 240x faster than standard structured cloning. | |
| ### [`SubtleCrypto`](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto) |
🤖 Prompt for AI Agents
In docs/runtime/nodejs-apis.md around lines 409-411, the standalone "###
Performance" note should be moved and integrated as a paragraph under the
structuredClone() entry (lines ~405-407) to preserve heading hierarchy; replace
the heading with a short "Note:" sentence attached to structuredClone(), and
update the performance claim to specify what "standard structured cloning"
refers to (e.g., Node.js built-in structuredClone or spec baseline), define
"simple objects containing only primitives" (e.g., flat objects whose values are
only number/string/boolean/null/undefined with no nested
objects/arrays/functions/DOM), and either add a source/citation for the "up to
240x faster" figure or qualify it as a benchmark result under specific
conditions (include environment, Node version, and benchmark methodology) so
readers understand the context and limitations of the claim.
Summary
Changes
Test plan
🤖 Generated with Claude Code