bun-types 1.3.3-canary.20251115T140608 → 1.3.3-canary.20251116T140533
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bun.d.ts +1 -1
- package/docs/bundler/executables.mdx +37 -3
- package/docs/bundler/index.mdx +1 -1
- package/docs/guides/html-rewriter/extract-links.mdx +5 -6
- package/docs/guides/http/file-uploads.mdx +2 -2
- package/docs/guides/install/add-peer.mdx +2 -2
- package/docs/guides/runtime/cicd.mdx +6 -6
- package/docs/guides/runtime/define-constant.mdx +4 -4
- package/docs/guides/test/concurrent-test-glob.mdx +143 -0
- package/docs/guides/test/spy-on.mdx +2 -2
- package/docs/guides/websocket/context.mdx +8 -3
- package/docs/guides/websocket/pubsub.mdx +4 -1
- package/docs/guides/websocket/simple.mdx +4 -1
- package/docs/pm/cli/info.mdx +70 -0
- package/docs/pm/cli/install.mdx +123 -4
- package/docs/pm/cli/link.mdx +13 -0
- package/docs/pm/cli/publish.mdx +8 -0
- package/docs/pm/overrides.mdx +6 -6
- package/docs/pm/workspaces.mdx +13 -5
- package/docs/project/contributing.mdx +60 -15
- package/docs/quickstart.mdx +8 -3
- package/docs/runtime/bunfig.mdx +53 -1
- package/docs/runtime/html-rewriter.mdx +13 -20
- package/docs/runtime/http/routing.mdx +1 -1
- package/docs/runtime/http/websockets.mdx +8 -2
- package/docs/runtime/module-resolution.mdx +23 -0
- package/docs/runtime/redis.mdx +1 -0
- package/docs/runtime/utils.mdx +2 -2
- package/docs/test/configuration.mdx +47 -0
- package/docs/test/reporters.mdx +9 -0
- package/package.json +1 -1
package/bun.d.ts
CHANGED
|
@@ -1788,7 +1788,7 @@ declare module "bun" {
|
|
|
1788
1788
|
* @see {@link outdir} required for `"linked"` maps
|
|
1789
1789
|
* @see {@link publicPath} to customize the base url of linked source maps
|
|
1790
1790
|
*/
|
|
1791
|
-
sourcemap?: "none" | "linked" | "inline" | "external" |
|
|
1791
|
+
sourcemap?: "none" | "linked" | "inline" | "external" | boolean;
|
|
1792
1792
|
|
|
1793
1793
|
/**
|
|
1794
1794
|
* package.json `exports` conditions used when resolving imports
|
|
@@ -90,7 +90,7 @@ The order of the `--target` flag does not matter, as long as they're delimited b
|
|
|
90
90
|
| bun-linux-x64 | Linux | x64 | ✅ | ✅ | glibc |
|
|
91
91
|
| bun-linux-arm64 | Linux | arm64 | ✅ | N/A | glibc |
|
|
92
92
|
| bun-windows-x64 | Windows | x64 | ✅ | ✅ | - |
|
|
93
|
-
| ~~bun-windows-arm64~~ | Windows
|
|
93
|
+
| ~~bun-windows-arm64~~ | ~~Windows~~ | ~~arm64~~ | ❌ | ❌ | - |
|
|
94
94
|
| bun-darwin-x64 | macOS | x64 | ✅ | ✅ | - |
|
|
95
95
|
| bun-darwin-arm64 | macOS | arm64 | ✅ | N/A | - |
|
|
96
96
|
| bun-linux-x64-musl | Linux | x64 | ✅ | ✅ | musl |
|
|
@@ -524,12 +524,46 @@ codesign -vvv --verify ./myapp
|
|
|
524
524
|
|
|
525
525
|
---
|
|
526
526
|
|
|
527
|
+
## Code splitting
|
|
528
|
+
|
|
529
|
+
Standalone executables support code splitting. Use `--compile` with `--splitting` to create an executable that loads code-split chunks at runtime.
|
|
530
|
+
|
|
531
|
+
```bash
|
|
532
|
+
bun build --compile --splitting ./src/entry.ts --outdir ./build
|
|
533
|
+
```
|
|
534
|
+
|
|
535
|
+
<CodeGroup>
|
|
536
|
+
|
|
537
|
+
```ts src/entry.ts icon="/icons/typescript.svg"
|
|
538
|
+
console.log("Entrypoint loaded");
|
|
539
|
+
const lazy = await import("./lazy.ts");
|
|
540
|
+
lazy.hello();
|
|
541
|
+
```
|
|
542
|
+
|
|
543
|
+
```ts src/lazy.ts icon="/icons/typescript.svg"
|
|
544
|
+
export function hello() {
|
|
545
|
+
console.log("Lazy module loaded");
|
|
546
|
+
}
|
|
547
|
+
```
|
|
548
|
+
|
|
549
|
+
</CodeGroup>
|
|
550
|
+
|
|
551
|
+
```bash terminal icon="terminal"
|
|
552
|
+
./build/entry
|
|
553
|
+
```
|
|
554
|
+
|
|
555
|
+
```txt
|
|
556
|
+
Entrypoint loaded
|
|
557
|
+
Lazy module loaded
|
|
558
|
+
```
|
|
559
|
+
|
|
560
|
+
---
|
|
561
|
+
|
|
527
562
|
## Unsupported CLI arguments
|
|
528
563
|
|
|
529
564
|
Currently, the `--compile` flag can only accept a single entrypoint at a time and does not support the following flags:
|
|
530
565
|
|
|
531
|
-
- `--outdir` — use `outfile` instead.
|
|
532
|
-
- `--splitting`
|
|
566
|
+
- `--outdir` — use `outfile` instead (except when using with `--splitting`).
|
|
533
567
|
- `--public-path`
|
|
534
568
|
- `--target=node` or `--target=browser`
|
|
535
569
|
- `--no-bundle` - we always bundle everything into the executable.
|
package/docs/bundler/index.mdx
CHANGED
|
@@ -1376,7 +1376,7 @@ interface BuildConfig {
|
|
|
1376
1376
|
publicPath?: string;
|
|
1377
1377
|
define?: Record<string, string>;
|
|
1378
1378
|
loader?: { [k in string]: Loader };
|
|
1379
|
-
sourcemap?: "none" | "linked" | "inline" | "external" |
|
|
1379
|
+
sourcemap?: "none" | "linked" | "inline" | "external" | boolean; // default: "none", true -> "inline"
|
|
1380
1380
|
/**
|
|
1381
1381
|
* package.json `exports` conditions used when resolving imports
|
|
1382
1382
|
*
|
|
@@ -37,6 +37,7 @@ await extractLinks("https://bun.com");
|
|
|
37
37
|
|
|
38
38
|
When scraping websites, you often want to convert relative URLs (like `/docs`) to absolute URLs. Here's how to handle URL resolution:
|
|
39
39
|
|
|
40
|
+
{/* prettier-ignore */}
|
|
40
41
|
```ts extract-links.ts icon="/icons/typescript.svg"
|
|
41
42
|
async function extractLinksFromURL(url: string) {
|
|
42
43
|
const response = await fetch(url);
|
|
@@ -47,13 +48,11 @@ async function extractLinksFromURL(url: string) {
|
|
|
47
48
|
const href = el.getAttribute("href");
|
|
48
49
|
if (href) {
|
|
49
50
|
// Convert relative URLs to absolute // [!code ++]
|
|
50
|
-
try {
|
|
51
|
-
// [!code ++]
|
|
51
|
+
try { // [!code ++]
|
|
52
52
|
const absoluteURL = new URL(href, url).href; // [!code ++]
|
|
53
|
-
links.add(absoluteURL);
|
|
54
|
-
} catch {
|
|
55
|
-
// [!code ++]
|
|
56
|
-
links.add(href);
|
|
53
|
+
links.add(absoluteURL);
|
|
54
|
+
} catch { // [!code ++]
|
|
55
|
+
links.add(href); // [!code ++]
|
|
57
56
|
} // [!code ++]
|
|
58
57
|
}
|
|
59
58
|
},
|
|
@@ -65,6 +65,7 @@ First we use the [`.formData()`](https://developer.mozilla.org/en-US/docs/Web/AP
|
|
|
65
65
|
|
|
66
66
|
Finally, we write the `Blob` to disk using [`Bun.write()`](https://bun.com/docs/api/file-io#writing-files-bun-write).
|
|
67
67
|
|
|
68
|
+
{/* prettier-ignore */}
|
|
68
69
|
```ts index.ts icon="/icons/typescript.svg"
|
|
69
70
|
const server = Bun.serve({
|
|
70
71
|
port: 4000,
|
|
@@ -80,8 +81,7 @@ const server = Bun.serve({
|
|
|
80
81
|
});
|
|
81
82
|
|
|
82
83
|
// parse formdata at /action // [!code ++]
|
|
83
|
-
if (url.pathname === "/action") {
|
|
84
|
-
// [!code ++]
|
|
84
|
+
if (url.pathname === "/action") { // [!code ++]
|
|
85
85
|
const formdata = await req.formData(); // [!code ++]
|
|
86
86
|
const name = formdata.get("name"); // [!code ++]
|
|
87
87
|
const profilePicture = formdata.get("profilePicture"); // [!code ++]
|
|
@@ -26,14 +26,14 @@ This will add the package to `peerDependencies` in `package.json`.
|
|
|
26
26
|
|
|
27
27
|
Running `bun install` will install peer dependencies by default, unless marked optional in `peerDependenciesMeta`.
|
|
28
28
|
|
|
29
|
+
{/* prettier-ignore */}
|
|
29
30
|
```json package.json icon="file-json"
|
|
30
31
|
{
|
|
31
32
|
"peerDependencies": {
|
|
32
33
|
"@types/bun": "^1.3.2"
|
|
33
34
|
},
|
|
34
35
|
"peerDependenciesMeta": {
|
|
35
|
-
"@types/bun": {
|
|
36
|
-
// [!code ++]
|
|
36
|
+
"@types/bun": { // [!code ++]
|
|
37
37
|
"optional": true // [!code ++]
|
|
38
38
|
} // [!code ++]
|
|
39
39
|
}
|
|
@@ -15,12 +15,12 @@ jobs:
|
|
|
15
15
|
steps:
|
|
16
16
|
# ...
|
|
17
17
|
- uses: actions/checkout@v4
|
|
18
|
-
- uses: oven-sh/setup-bun@v2
|
|
18
|
+
- uses: oven-sh/setup-bun@v2 # [!code ++]
|
|
19
19
|
|
|
20
20
|
# run any `bun` or `bunx` command
|
|
21
|
-
- run: bun install
|
|
22
|
-
- run: bun index.ts
|
|
23
|
-
- run: bun run build
|
|
21
|
+
- run: bun install # [!code ++]
|
|
22
|
+
- run: bun index.ts # [!code ++]
|
|
23
|
+
- run: bun run build # [!code ++]
|
|
24
24
|
```
|
|
25
25
|
|
|
26
26
|
---
|
|
@@ -36,8 +36,8 @@ jobs:
|
|
|
36
36
|
steps:
|
|
37
37
|
# ...
|
|
38
38
|
- uses: oven-sh/setup-bun@v2
|
|
39
|
-
with:
|
|
40
|
-
bun-version: 1.2.0 # or "latest", "canary", <sha>
|
|
39
|
+
with: # [!code ++]
|
|
40
|
+
bun-version: 1.2.0 # or "latest", "canary", <sha> # [!code ++]
|
|
41
41
|
```
|
|
42
42
|
|
|
43
43
|
---
|
|
@@ -27,9 +27,9 @@ if (process.env.NODE_ENV === "production") {
|
|
|
27
27
|
|
|
28
28
|
Before the code reaches the JavaScript engine, Bun replaces `process.env.NODE_ENV` with `"production"`.
|
|
29
29
|
|
|
30
|
+
{/* prettier-ignore */}
|
|
30
31
|
```ts
|
|
31
|
-
if ("production" === "production") {
|
|
32
|
-
// [!code ++]
|
|
32
|
+
if ("production" === "production") { // [!code ++]
|
|
33
33
|
console.log("Production mode");
|
|
34
34
|
} else {
|
|
35
35
|
console.log("Development mode");
|
|
@@ -42,9 +42,9 @@ It doesn't stop there. Bun's optimizing transpiler is smart enough to do some ba
|
|
|
42
42
|
|
|
43
43
|
Since `"production" === "production"` is always `true`, Bun replaces the entire expression with the `true` value.
|
|
44
44
|
|
|
45
|
+
{/* prettier-ignore */}
|
|
45
46
|
```ts
|
|
46
|
-
if (true) {
|
|
47
|
-
// [!code ++]
|
|
47
|
+
if (true) { // [!code ++]
|
|
48
48
|
console.log("Production mode");
|
|
49
49
|
} else {
|
|
50
50
|
console.log("Development mode");
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Selectively run tests concurrently with glob patterns
|
|
3
|
+
sidebarTitle: Concurrent test glob
|
|
4
|
+
mode: center
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
This guide demonstrates how to use the `concurrentTestGlob` option to selectively run tests concurrently based on file naming patterns.
|
|
8
|
+
|
|
9
|
+
## Project Structure
|
|
10
|
+
|
|
11
|
+
```sh title="Project Structure" icon="folder-tree"
|
|
12
|
+
my-project/
|
|
13
|
+
├── bunfig.toml
|
|
14
|
+
├── tests/
|
|
15
|
+
│ ├── unit/
|
|
16
|
+
│ │ ├── math.test.ts # Sequential
|
|
17
|
+
│ │ └── utils.test.ts # Sequential
|
|
18
|
+
│ └── integration/
|
|
19
|
+
│ ├── concurrent-api.test.ts # Concurrent
|
|
20
|
+
│ └── concurrent-database.test.ts # Concurrent
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Configuration
|
|
24
|
+
|
|
25
|
+
Configure your `bunfig.toml` to run test files with "concurrent-" prefix concurrently:
|
|
26
|
+
|
|
27
|
+
```toml title="bunfig.toml" icon="settings"
|
|
28
|
+
[test]
|
|
29
|
+
# Run all test files with "concurrent-" prefix concurrently
|
|
30
|
+
concurrentTestGlob = "**/concurrent-*.test.ts"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Test Files
|
|
34
|
+
|
|
35
|
+
### Unit Test (Sequential)
|
|
36
|
+
|
|
37
|
+
Sequential tests are good for tests that share state or have specific ordering requirements:
|
|
38
|
+
|
|
39
|
+
```ts title="tests/unit/math.test.ts" icon="/icons/typescript.svg"
|
|
40
|
+
import { test, expect } from "bun:test";
|
|
41
|
+
|
|
42
|
+
// These tests run sequentially by default
|
|
43
|
+
let sharedState = 0;
|
|
44
|
+
|
|
45
|
+
test("addition", () => {
|
|
46
|
+
sharedState = 5 + 3;
|
|
47
|
+
expect(sharedState).toBe(8);
|
|
48
|
+
});
|
|
49
|
+
|
|
50
|
+
test("uses previous state", () => {
|
|
51
|
+
// This test depends on the previous test's state
|
|
52
|
+
expect(sharedState).toBe(8);
|
|
53
|
+
});
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### Integration Test (Concurrent)
|
|
57
|
+
|
|
58
|
+
Tests in files matching the glob pattern automatically run concurrently:
|
|
59
|
+
|
|
60
|
+
```ts title="tests/integration/concurrent-api.test.ts" icon="/icons/typescript.svg"
|
|
61
|
+
import { test, expect } from "bun:test";
|
|
62
|
+
|
|
63
|
+
// These tests automatically run concurrently due to filename matching the glob pattern.
|
|
64
|
+
// Using test() is equivalent to test.concurrent() when the file matches concurrentTestGlob.
|
|
65
|
+
// Each test is independent and can run in parallel.
|
|
66
|
+
|
|
67
|
+
test("fetch user data", async () => {
|
|
68
|
+
const response = await fetch("/api/user/1");
|
|
69
|
+
expect(response.ok).toBe(true);
|
|
70
|
+
});
|
|
71
|
+
|
|
72
|
+
test("fetch posts", async () => {
|
|
73
|
+
const response = await fetch("/api/posts");
|
|
74
|
+
expect(response.ok).toBe(true);
|
|
75
|
+
});
|
|
76
|
+
|
|
77
|
+
test("fetch comments", async () => {
|
|
78
|
+
const response = await fetch("/api/comments");
|
|
79
|
+
expect(response.ok).toBe(true);
|
|
80
|
+
});
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Running Tests
|
|
84
|
+
|
|
85
|
+
```bash terminal icon="terminal"
|
|
86
|
+
# Run all tests - concurrent-*.test.ts files will run concurrently
|
|
87
|
+
bun test
|
|
88
|
+
|
|
89
|
+
# Override: Force ALL tests to run concurrently
|
|
90
|
+
# Note: This overrides bunfig.toml and runs all tests concurrently, regardless of glob
|
|
91
|
+
bun test --concurrent
|
|
92
|
+
|
|
93
|
+
# Run only unit tests (sequential)
|
|
94
|
+
bun test tests/unit
|
|
95
|
+
|
|
96
|
+
# Run only integration tests (concurrent due to glob pattern)
|
|
97
|
+
bun test tests/integration
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
## Benefits
|
|
101
|
+
|
|
102
|
+
1. **Gradual Migration**: Migrate to concurrent tests file by file by renaming them
|
|
103
|
+
2. **Clear Organization**: File naming convention indicates execution mode
|
|
104
|
+
3. **Performance**: Integration tests run faster in parallel
|
|
105
|
+
4. **Safety**: Unit tests remain sequential where needed
|
|
106
|
+
5. **Flexibility**: Easy to change execution mode by renaming files
|
|
107
|
+
|
|
108
|
+
## Migration Strategy
|
|
109
|
+
|
|
110
|
+
To migrate existing tests to concurrent execution:
|
|
111
|
+
|
|
112
|
+
1. **Start with independent integration tests** - These typically don't share state
|
|
113
|
+
2. **Rename files to match the glob pattern**: `mv api.test.ts concurrent-api.test.ts`
|
|
114
|
+
3. **Verify tests still pass** - Run `bun test` to ensure no race conditions
|
|
115
|
+
4. **Monitor for shared state issues** - Watch for flaky tests or unexpected failures
|
|
116
|
+
5. **Continue migrating stable tests incrementally** - Don't rush the migration
|
|
117
|
+
|
|
118
|
+
## Tips
|
|
119
|
+
|
|
120
|
+
- **Use descriptive prefixes**: `concurrent-`, `parallel-`, `async-`
|
|
121
|
+
- **Keep related sequential tests together** in the same directory
|
|
122
|
+
- **Document why certain tests must remain sequential** with comments
|
|
123
|
+
- **Use `test.concurrent()` for fine-grained control** in sequential files
|
|
124
|
+
(Note: In files matched by `concurrentTestGlob`, plain `test()` already runs concurrently)
|
|
125
|
+
|
|
126
|
+
## Multiple Patterns
|
|
127
|
+
|
|
128
|
+
You can specify multiple patterns for different test categories:
|
|
129
|
+
|
|
130
|
+
```toml title="bunfig.toml" icon="settings"
|
|
131
|
+
[test]
|
|
132
|
+
concurrentTestGlob = [
|
|
133
|
+
"**/integration/*.test.ts",
|
|
134
|
+
"**/e2e/*.test.ts",
|
|
135
|
+
"**/concurrent-*.test.ts"
|
|
136
|
+
]
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
This configuration will run tests concurrently if they match any of these patterns:
|
|
140
|
+
|
|
141
|
+
- All tests in `integration/` directories
|
|
142
|
+
- All tests in `e2e/` directories
|
|
143
|
+
- All tests with `concurrent-` prefix anywhere in the project
|
|
@@ -23,6 +23,7 @@ const spy = spyOn(leo, "sayHi");
|
|
|
23
23
|
|
|
24
24
|
Once the spy is created, it can be used to write `expect` assertions relating to method calls.
|
|
25
25
|
|
|
26
|
+
{/* prettier-ignore */}
|
|
26
27
|
```ts
|
|
27
28
|
import { test, expect, spyOn } from "bun:test";
|
|
28
29
|
|
|
@@ -35,8 +36,7 @@ const leo = {
|
|
|
35
36
|
|
|
36
37
|
const spy = spyOn(leo, "sayHi");
|
|
37
38
|
|
|
38
|
-
test("turtles", () => {
|
|
39
|
-
// [!code ++]
|
|
39
|
+
test("turtles", () => { // [!code ++]
|
|
40
40
|
expect(spy).toHaveBeenCalledTimes(0); // [!code ++]
|
|
41
41
|
leo.sayHi("pizza"); // [!code ++]
|
|
42
42
|
expect(spy).toHaveBeenCalledTimes(1); // [!code ++]
|
|
@@ -9,7 +9,7 @@ When building a WebSocket server, it's typically necessary to store some identif
|
|
|
9
9
|
With [Bun.serve()](https://bun.com/docs/api/websockets contextual-data), this "contextual data" is set when the connection is initially upgraded by passing a `data` parameter in the `server.upgrade()` call.
|
|
10
10
|
|
|
11
11
|
```ts server.ts icon="/icons/typescript.svg"
|
|
12
|
-
Bun.serve
|
|
12
|
+
Bun.serve({
|
|
13
13
|
fetch(req, server) {
|
|
14
14
|
const success = server.upgrade(req, {
|
|
15
15
|
data: {
|
|
@@ -22,6 +22,9 @@ Bun.serve<{ socketId: number }>({
|
|
|
22
22
|
// ...
|
|
23
23
|
},
|
|
24
24
|
websocket: {
|
|
25
|
+
// TypeScript: specify the type of ws.data like this
|
|
26
|
+
data: {} as { socketId: number },
|
|
27
|
+
|
|
25
28
|
// define websocket handlers
|
|
26
29
|
async message(ws, message) {
|
|
27
30
|
// the contextual data is available as the `data` property
|
|
@@ -43,8 +46,7 @@ type WebSocketData = {
|
|
|
43
46
|
userId: string;
|
|
44
47
|
};
|
|
45
48
|
|
|
46
|
-
|
|
47
|
-
Bun.serve<WebSocketData>({
|
|
49
|
+
Bun.serve({
|
|
48
50
|
async fetch(req, server) {
|
|
49
51
|
// use a library to parse cookies
|
|
50
52
|
const cookies = parseCookies(req.headers.get("Cookie"));
|
|
@@ -62,6 +64,9 @@ Bun.serve<WebSocketData>({
|
|
|
62
64
|
if (upgraded) return undefined;
|
|
63
65
|
},
|
|
64
66
|
websocket: {
|
|
67
|
+
// TypeScript: specify the type of ws.data like this
|
|
68
|
+
data: {} as WebSocketData,
|
|
69
|
+
|
|
65
70
|
async message(ws, message) {
|
|
66
71
|
// save the message to a database
|
|
67
72
|
await saveMessageToDatabase({
|
|
@@ -9,7 +9,7 @@ Bun's server-side `WebSocket` API provides a native pub-sub API. Sockets can be
|
|
|
9
9
|
This code snippet implements a simple single-channel chat server.
|
|
10
10
|
|
|
11
11
|
```ts server.ts icon="/icons/typescript.svg"
|
|
12
|
-
const server = Bun.serve
|
|
12
|
+
const server = Bun.serve({
|
|
13
13
|
fetch(req, server) {
|
|
14
14
|
const cookies = req.headers.get("cookie");
|
|
15
15
|
const username = getUsernameFromCookies(cookies);
|
|
@@ -19,6 +19,9 @@ const server = Bun.serve<{ username: string }>({
|
|
|
19
19
|
return new Response("Hello world");
|
|
20
20
|
},
|
|
21
21
|
websocket: {
|
|
22
|
+
// TypeScript: specify the type of ws.data like this
|
|
23
|
+
data: {} as { username: string },
|
|
24
|
+
|
|
22
25
|
open(ws) {
|
|
23
26
|
const msg = `${ws.data.username} has entered the chat`;
|
|
24
27
|
ws.subscribe("the-group-chat");
|
|
@@ -9,7 +9,7 @@ Start a simple WebSocket server using [`Bun.serve`](https://bun.com/docs/api/htt
|
|
|
9
9
|
Inside `fetch`, we attempt to upgrade incoming `ws:` or `wss:` requests to WebSocket connections.
|
|
10
10
|
|
|
11
11
|
```ts server.ts icon="/icons/typescript.svg"
|
|
12
|
-
const server = Bun.serve
|
|
12
|
+
const server = Bun.serve({
|
|
13
13
|
fetch(req, server) {
|
|
14
14
|
const success = server.upgrade(req);
|
|
15
15
|
if (success) {
|
|
@@ -22,6 +22,9 @@ const server = Bun.serve<{ authToken: string }>({
|
|
|
22
22
|
return new Response("Hello world!");
|
|
23
23
|
},
|
|
24
24
|
websocket: {
|
|
25
|
+
// TypeScript: specify the type of ws.data like this
|
|
26
|
+
data: {} as { authToken: string },
|
|
27
|
+
|
|
25
28
|
// this is called when a message is received
|
|
26
29
|
async message(ws, message) {
|
|
27
30
|
console.log(`Received ${message}`);
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "bun info"
|
|
3
|
+
description: "Display package metadata from the npm registry"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
`bun info` displays package metadata from the npm registry.
|
|
7
|
+
|
|
8
|
+
## Usage
|
|
9
|
+
|
|
10
|
+
```bash terminal icon="terminal"
|
|
11
|
+
bun info react
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
This will display information about the `react` package, including its latest version, description, homepage, dependencies, and more.
|
|
15
|
+
|
|
16
|
+
## Viewing specific versions
|
|
17
|
+
|
|
18
|
+
To view information about a specific version:
|
|
19
|
+
|
|
20
|
+
```bash terminal icon="terminal"
|
|
21
|
+
bun info react@18.0.0
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Viewing specific properties
|
|
25
|
+
|
|
26
|
+
You can also query specific properties from the package metadata:
|
|
27
|
+
|
|
28
|
+
```bash terminal icon="terminal"
|
|
29
|
+
bun info react version
|
|
30
|
+
bun info react dependencies
|
|
31
|
+
bun info react repository.url
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## JSON output
|
|
35
|
+
|
|
36
|
+
To get the output in JSON format, use the `--json` flag:
|
|
37
|
+
|
|
38
|
+
```bash terminal icon="terminal"
|
|
39
|
+
bun info react --json
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
## Alias
|
|
43
|
+
|
|
44
|
+
`bun pm view` is an alias for `bun info`:
|
|
45
|
+
|
|
46
|
+
```bash terminal icon="terminal"
|
|
47
|
+
bun pm view react # equivalent to: bun info react
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## Examples
|
|
51
|
+
|
|
52
|
+
```bash terminal icon="terminal"
|
|
53
|
+
# View basic package information
|
|
54
|
+
bun info is-number
|
|
55
|
+
|
|
56
|
+
# View a specific version
|
|
57
|
+
bun info is-number@7.0.0
|
|
58
|
+
|
|
59
|
+
# View all available versions
|
|
60
|
+
bun info is-number versions
|
|
61
|
+
|
|
62
|
+
# View package dependencies
|
|
63
|
+
bun info express dependencies
|
|
64
|
+
|
|
65
|
+
# View package homepage
|
|
66
|
+
bun info lodash homepage
|
|
67
|
+
|
|
68
|
+
# Get JSON output
|
|
69
|
+
bun info react --json
|
|
70
|
+
```
|
package/docs/pm/cli/install.mdx
CHANGED
|
@@ -134,14 +134,14 @@ For more information on filtering with `bun install`, refer to [Package Manager
|
|
|
134
134
|
|
|
135
135
|
Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. These are mechanisms for specifying a version range for _metadependencies_—the dependencies of your dependencies. Refer to [Package manager > Overrides and resolutions](/pm/overrides) for complete documentation.
|
|
136
136
|
|
|
137
|
+
{/* prettier-ignore */}
|
|
137
138
|
```json package.json file="file-json"
|
|
138
139
|
{
|
|
139
140
|
"name": "my-app",
|
|
140
141
|
"dependencies": {
|
|
141
142
|
"foo": "^2.0.0"
|
|
142
143
|
},
|
|
143
|
-
"overrides": {
|
|
144
|
-
// [!code ++]
|
|
144
|
+
"overrides": { // [!code ++]
|
|
145
145
|
"bar": "~4.4.0" // [!code ++]
|
|
146
146
|
} // [!code ++]
|
|
147
147
|
}
|
|
@@ -304,7 +304,16 @@ For more advanced security scanning, including integration with services & custo
|
|
|
304
304
|
|
|
305
305
|
## Configuration
|
|
306
306
|
|
|
307
|
-
|
|
307
|
+
### Configuring `bun install` with `bunfig.toml`
|
|
308
|
+
|
|
309
|
+
`bunfig.toml` is searched for in the following paths on `bun install`, `bun remove`, and `bun add`:
|
|
310
|
+
|
|
311
|
+
1. `$XDG_CONFIG_HOME/.bunfig.toml` or `$HOME/.bunfig.toml`
|
|
312
|
+
2. `./bunfig.toml`
|
|
313
|
+
|
|
314
|
+
If both are found, the results are merged together.
|
|
315
|
+
|
|
316
|
+
Configuring with `bunfig.toml` is optional. Bun tries to be zero configuration in general, but that's not always possible. The default behavior of `bun install` can be configured in `bunfig.toml`. The default values are shown below.
|
|
308
317
|
|
|
309
318
|
```toml bunfig.toml icon="settings"
|
|
310
319
|
[install]
|
|
@@ -345,7 +354,29 @@ minimumReleaseAge = 259200 # seconds
|
|
|
345
354
|
minimumReleaseAgeExcludes = ["@types/node", "typescript"]
|
|
346
355
|
```
|
|
347
356
|
|
|
348
|
-
|
|
357
|
+
### Configuring with environment variables
|
|
358
|
+
|
|
359
|
+
Environment variables have a higher priority than `bunfig.toml`.
|
|
360
|
+
|
|
361
|
+
| Name | Description |
|
|
362
|
+
| ---------------------------------- | ------------------------------------------------------------- |
|
|
363
|
+
| `BUN_CONFIG_REGISTRY` | Set an npm registry (default: https://registry.npmjs.org) |
|
|
364
|
+
| `BUN_CONFIG_TOKEN` | Set an auth token (currently does nothing) |
|
|
365
|
+
| `BUN_CONFIG_YARN_LOCKFILE` | Save a Yarn v1-style yarn.lock |
|
|
366
|
+
| `BUN_CONFIG_LINK_NATIVE_BINS` | Point `bin` in package.json to a platform-specific dependency |
|
|
367
|
+
| `BUN_CONFIG_SKIP_SAVE_LOCKFILE` | Don’t save a lockfile |
|
|
368
|
+
| `BUN_CONFIG_SKIP_LOAD_LOCKFILE` | Don’t load a lockfile |
|
|
369
|
+
| `BUN_CONFIG_SKIP_INSTALL_PACKAGES` | Don’t install any packages |
|
|
370
|
+
|
|
371
|
+
Bun always tries to use the fastest available installation method for the target platform. On macOS, that’s `clonefile` and on Linux, that’s `hardlink`. You can change which installation method is used with the `--backend` flag. When unavailable or on error, `clonefile` and `hardlink` fallsback to a platform-specific implementation of copying files.
|
|
372
|
+
|
|
373
|
+
Bun stores installed packages from npm in `~/.bun/install/cache/${name}@${version}`. Note that if the semver version has a `build` or a `pre` tag, it is replaced with a hash of that value instead. This is to reduce the chances of errors from long file paths, but unfortunately complicates figuring out where a package was installed on disk.
|
|
374
|
+
|
|
375
|
+
When the `node_modules` folder exists, before installing, Bun checks if the `"name"` and `"version"` in `package/package.json` in the expected node_modules folder matches the expected `name` and `version`. This is how it determines whether it should install. It uses a custom JSON parser which stops parsing as soon as it finds `"name"` and `"version"`.
|
|
376
|
+
|
|
377
|
+
When a `bun.lock` doesn’t exist or `package.json` has changed dependencies, tarballs are downloaded & extracted eagerly while resolving.
|
|
378
|
+
|
|
379
|
+
When a `bun.lock` exists and `package.json` hasn’t changed, Bun downloads missing dependencies lazily. If the package with a matching `name` & `version` already exists in the expected location within `node_modules`, Bun won’t attempt to download the tarball.
|
|
349
380
|
|
|
350
381
|
## CI/CD
|
|
351
382
|
|
|
@@ -395,6 +426,94 @@ jobs:
|
|
|
395
426
|
run: bun run build
|
|
396
427
|
```
|
|
397
428
|
|
|
429
|
+
## Platform-specific dependencies?
|
|
430
|
+
|
|
431
|
+
bun stores normalized `cpu` and `os` values from npm in the lockfile, along with the resolved packages. It skips downloading, extracting, and installing packages disabled for the current target at runtime. This means the lockfile won't change between platforms/architectures even if the packages ultimately installed do change.
|
|
432
|
+
|
|
433
|
+
### `--cpu` and `--os` flags
|
|
434
|
+
|
|
435
|
+
You can override the target platform for package selection:
|
|
436
|
+
|
|
437
|
+
```bash
|
|
438
|
+
bun install --cpu=x64 --os=linux
|
|
439
|
+
```
|
|
440
|
+
|
|
441
|
+
This installs packages for the specified platform instead of the current system. Useful for cross-platform builds or when preparing deployments for different environments.
|
|
442
|
+
|
|
443
|
+
**Accepted values for `--cpu`**: `arm64`, `x64`, `ia32`, `ppc64`, `s390x`
|
|
444
|
+
|
|
445
|
+
**Accepted values for `--os`**: `linux`, `darwin`, `win32`, `freebsd`, `openbsd`, `sunos`, `aix`
|
|
446
|
+
|
|
447
|
+
## Peer dependencies?
|
|
448
|
+
|
|
449
|
+
Peer dependencies are handled similarly to yarn. `bun install` will automatically install peer dependencies. If the dependency is marked optional in `peerDependenciesMeta`, an existing dependency will be chosen if possible.
|
|
450
|
+
|
|
451
|
+
## Lockfile
|
|
452
|
+
|
|
453
|
+
`bun.lock` is Bun’s lockfile format. See [our blogpost about the text lockfile](https://bun.com/blog/bun-lock-text-lockfile).
|
|
454
|
+
|
|
455
|
+
Prior to Bun 1.2, the lockfile was binary and called `bun.lockb`. Old lockfiles can be upgraded to the new format by running `bun install --save-text-lockfile --frozen-lockfile --lockfile-only`, and then deleting `bun.lockb`.
|
|
456
|
+
|
|
457
|
+
## Cache
|
|
458
|
+
|
|
459
|
+
To delete the cache:
|
|
460
|
+
|
|
461
|
+
```bash
|
|
462
|
+
bun pm cache rm
|
|
463
|
+
# or
|
|
464
|
+
rm -rf ~/.bun/install/cache
|
|
465
|
+
```
|
|
466
|
+
|
|
467
|
+
## Platform-specific backends
|
|
468
|
+
|
|
469
|
+
`bun install` uses different system calls to install dependencies depending on the platform. This is a performance optimization. You can force a specific backend with the `--backend` flag.
|
|
470
|
+
|
|
471
|
+
**`hardlink`** is the default backend on Linux. Benchmarking showed it to be the fastest on Linux.
|
|
472
|
+
|
|
473
|
+
```bash
|
|
474
|
+
rm -rf node_modules
|
|
475
|
+
bun install --backend hardlink
|
|
476
|
+
```
|
|
477
|
+
|
|
478
|
+
**`clonefile`** is the default backend on macOS. Benchmarking showed it to be the fastest on macOS. It is only available on macOS.
|
|
479
|
+
|
|
480
|
+
```bash
|
|
481
|
+
rm -rf node_modules
|
|
482
|
+
bun install --backend clonefile
|
|
483
|
+
```
|
|
484
|
+
|
|
485
|
+
**`clonefile_each_dir`** is similar to `clonefile`, except it clones each file individually per directory. It is only available on macOS and tends to perform slower than `clonefile`. Unlike `clonefile`, this does not recursively clone subdirectories in one system call.
|
|
486
|
+
|
|
487
|
+
```bash
|
|
488
|
+
rm -rf node_modules
|
|
489
|
+
bun install --backend clonefile_each_dir
|
|
490
|
+
```
|
|
491
|
+
|
|
492
|
+
**`copyfile`** is the fallback used when any of the above fail, and is the slowest. on macOS, it uses `fcopyfile()` and on linux it uses `copy_file_range()`.
|
|
493
|
+
|
|
494
|
+
```bash
|
|
495
|
+
rm -rf node_modules
|
|
496
|
+
bun install --backend copyfile
|
|
497
|
+
```
|
|
498
|
+
|
|
499
|
+
**`symlink`** is typically only used for `file:` dependencies (and eventually `link:`) internally. To prevent infinite loops, it skips symlinking the `node_modules` folder.
|
|
500
|
+
|
|
501
|
+
If you install with `--backend=symlink`, Node.js won't resolve node_modules of dependencies unless each dependency has its own node_modules folder or you pass `--preserve-symlinks` to `node` or `bun`. See [Node.js documentation on `--preserve-symlinks`](https://nodejs.org/api/cli.html#--preserve-symlinks).
|
|
502
|
+
|
|
503
|
+
```bash
|
|
504
|
+
rm -rf node_modules
|
|
505
|
+
bun install --backend symlink
|
|
506
|
+
bun --preserve-symlinks ./my-file.js
|
|
507
|
+
node --preserve-symlinks ./my-file.js # https://nodejs.org/api/cli.html#--preserve-symlinks
|
|
508
|
+
```
|
|
509
|
+
|
|
510
|
+
## npm registry metadata
|
|
511
|
+
|
|
512
|
+
Bun uses a binary format for caching NPM registry responses. This loads much faster than JSON and tends to be smaller on disk.
|
|
513
|
+
You will see these files in `~/.bun/install/cache/*.npm`. The filename pattern is `${hash(packageName)}.npm`. It’s a hash so that extra directories don’t need to be created for scoped packages.
|
|
514
|
+
|
|
515
|
+
Bun's usage of `Cache-Control` ignores `Age`. This improves performance, but means bun may be about 5 minutes out of date to receive the latest package version metadata from npm.
|
|
516
|
+
|
|
398
517
|
## pnpm migration
|
|
399
518
|
|
|
400
519
|
Bun automatically migrates projects from pnpm to bun. When a `pnpm-lock.yaml` file is detected and no `bun.lock` file exists, Bun will automatically migrate the lockfile to `bun.lock` during installation. The original `pnpm-lock.yaml` file remains unmodified.
|
package/docs/pm/cli/link.mdx
CHANGED
|
@@ -43,6 +43,19 @@ In addition, the `--save` flag can be used to add `cool-pkg` to the `dependencie
|
|
|
43
43
|
}
|
|
44
44
|
```
|
|
45
45
|
|
|
46
|
+
## Unlinking
|
|
47
|
+
|
|
48
|
+
Use `bun unlink` in the root directory to unregister a local package.
|
|
49
|
+
|
|
50
|
+
```bash terminal icon="terminal"
|
|
51
|
+
cd /path/to/cool-pkg
|
|
52
|
+
bun unlink
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
```txt
|
|
56
|
+
bun unlink v1.x (7416672e)
|
|
57
|
+
```
|
|
58
|
+
|
|
46
59
|
---
|
|
47
60
|
|
|
48
61
|
<Link />
|
package/docs/pm/cli/publish.mdx
CHANGED
|
@@ -89,6 +89,14 @@ The `--dry-run` flag can be used to simulate the publish process without actuall
|
|
|
89
89
|
bun publish --dry-run
|
|
90
90
|
```
|
|
91
91
|
|
|
92
|
+
### `--tolerate-republish`
|
|
93
|
+
|
|
94
|
+
Exit with code 0 instead of 1 if the package version already exists. Useful in CI/CD where jobs may be re-run.
|
|
95
|
+
|
|
96
|
+
```sh terminal icon="terminal"
|
|
97
|
+
bun publish --tolerate-republish
|
|
98
|
+
```
|
|
99
|
+
|
|
92
100
|
### `--gzip-level`
|
|
93
101
|
|
|
94
102
|
Specify the level of gzip compression to use when packing the package. Only applies to `bun publish` without a tarball path argument. Values range from `0` to `9` (default is `9`).
|
package/docs/pm/overrides.mdx
CHANGED
|
@@ -5,14 +5,14 @@ description: "Control metadependency versions with npm overrides and Yarn resolu
|
|
|
5
5
|
|
|
6
6
|
Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. These are mechanisms for specifying a version range for _metadependencies_—the dependencies of your dependencies.
|
|
7
7
|
|
|
8
|
+
{/* prettier-ignore */}
|
|
8
9
|
```json package.json icon="file-json"
|
|
9
10
|
{
|
|
10
11
|
"name": "my-app",
|
|
11
12
|
"dependencies": {
|
|
12
13
|
"foo": "^2.0.0"
|
|
13
14
|
},
|
|
14
|
-
"overrides": {
|
|
15
|
-
// [!code ++]
|
|
15
|
+
"overrides": { // [!code ++]
|
|
16
16
|
"bar": "~4.4.0" // [!code ++]
|
|
17
17
|
} // [!code ++]
|
|
18
18
|
}
|
|
@@ -50,14 +50,14 @@ Add `bar` to the `"overrides"` field in `package.json`. Bun will defer to the sp
|
|
|
50
50
|
overrides](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides) are not supported.
|
|
51
51
|
</Note>
|
|
52
52
|
|
|
53
|
+
{/* prettier-ignore */}
|
|
53
54
|
```json package.json icon="file-json"
|
|
54
55
|
{
|
|
55
56
|
"name": "my-app",
|
|
56
57
|
"dependencies": {
|
|
57
58
|
"foo": "^2.0.0"
|
|
58
59
|
},
|
|
59
|
-
"overrides": {
|
|
60
|
-
// [!code ++]
|
|
60
|
+
"overrides": { // [!code ++]
|
|
61
61
|
"bar": "~4.4.0" // [!code ++]
|
|
62
62
|
} // [!code ++]
|
|
63
63
|
}
|
|
@@ -69,14 +69,14 @@ The syntax is similar for `"resolutions"`, which is Yarn's alternative to `"over
|
|
|
69
69
|
|
|
70
70
|
As with `"overrides"`, _nested resolutions_ are not currently supported.
|
|
71
71
|
|
|
72
|
+
{/* prettier-ignore */}
|
|
72
73
|
```json package.json icon="file-json"
|
|
73
74
|
{
|
|
74
75
|
"name": "my-app",
|
|
75
76
|
"dependencies": {
|
|
76
77
|
"foo": "^2.0.0"
|
|
77
78
|
},
|
|
78
|
-
"resolutions": {
|
|
79
|
-
// [!code ++]
|
|
79
|
+
"resolutions": { // [!code ++]
|
|
80
80
|
"bar": "~4.4.0" // [!code ++]
|
|
81
81
|
} // [!code ++]
|
|
82
82
|
}
|
package/docs/pm/workspaces.mdx
CHANGED
|
@@ -30,7 +30,7 @@ It's common for a monorepo to have the following structure:
|
|
|
30
30
|
|
|
31
31
|
In the root `package.json`, the `"workspaces"` key is used to indicate which subdirectories should be considered packages/workspaces within the monorepo. It's conventional to place all the workspace in a directory called `packages`.
|
|
32
32
|
|
|
33
|
-
```json
|
|
33
|
+
```json package.json icon="file-json"
|
|
34
34
|
{
|
|
35
35
|
"name": "my-project",
|
|
36
36
|
"version": "1.0.0",
|
|
@@ -42,14 +42,22 @@ In the root `package.json`, the `"workspaces"` key is used to indicate which sub
|
|
|
42
42
|
```
|
|
43
43
|
|
|
44
44
|
<Note>
|
|
45
|
-
**Glob support** — Bun supports full glob syntax in `"workspaces"
|
|
46
|
-
|
|
47
|
-
|
|
45
|
+
**Glob support** — Bun supports full glob syntax in `"workspaces"`, including negative patterns (e.g.
|
|
46
|
+
`!**/excluded/**`). See [here](https://bun.com/docs/api/glob#supported-glob-patterns) for a comprehensive list of
|
|
47
|
+
supported syntax.
|
|
48
48
|
</Note>
|
|
49
49
|
|
|
50
|
+
```json package.json icon="file-json"
|
|
51
|
+
{
|
|
52
|
+
"name": "my-project",
|
|
53
|
+
"version": "1.0.0",
|
|
54
|
+
"workspaces": ["packages/**", "!packages/**/test/**", "!packages/**/template/**"]
|
|
55
|
+
}
|
|
56
|
+
```
|
|
57
|
+
|
|
50
58
|
Each workspace has it's own `package.json`. When referencing other packages in the monorepo, semver or workspace protocols (e.g. `workspace:*`) can be used as the version field in your `package.json`.
|
|
51
59
|
|
|
52
|
-
```json
|
|
60
|
+
```json packages/pkg-a/package.json icon="file-json"
|
|
53
61
|
{
|
|
54
62
|
"name": "pkg-a",
|
|
55
63
|
"version": "1.0.0",
|
|
@@ -7,26 +7,40 @@ Configuring a development environment for Bun can take 10-30 minutes depending o
|
|
|
7
7
|
|
|
8
8
|
If you are using Windows, please refer to [this guide](/project/building-windows)
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Using Nix (Alternative)
|
|
11
|
+
|
|
12
|
+
A Nix flake is provided as an alternative to manual dependency installation:
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
nix develop
|
|
16
|
+
# or explicitly use the pure shell
|
|
17
|
+
# nix develop .#pure
|
|
18
|
+
export CMAKE_SYSTEM_PROCESSOR=$(uname -m)
|
|
19
|
+
bun bd
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
This provides all dependencies in an isolated, reproducible environment without requiring sudo.
|
|
23
|
+
|
|
24
|
+
## Install Dependencies (Manual)
|
|
11
25
|
|
|
12
26
|
Using your system's package manager, install Bun's dependencies:
|
|
13
27
|
|
|
14
28
|
<CodeGroup>
|
|
15
29
|
|
|
16
30
|
```bash macOS (Homebrew)
|
|
17
|
-
$ brew install automake
|
|
31
|
+
$ brew install automake cmake coreutils gnu-sed go icu4c libiconv libtool ninja pkg-config rust ruby sccache
|
|
18
32
|
```
|
|
19
33
|
|
|
20
34
|
```bash Ubuntu/Debian
|
|
21
|
-
$ sudo apt install curl wget lsb-release software-properties-common cargo
|
|
35
|
+
$ sudo apt install curl wget lsb-release software-properties-common cargo cmake git golang libtool ninja-build pkg-config rustc ruby-full xz-utils
|
|
22
36
|
```
|
|
23
37
|
|
|
24
38
|
```bash Arch
|
|
25
|
-
$ sudo pacman -S base-devel
|
|
39
|
+
$ sudo pacman -S base-devel cmake git go libiconv libtool make ninja pkg-config python rust sed unzip ruby
|
|
26
40
|
```
|
|
27
41
|
|
|
28
42
|
```bash Fedora
|
|
29
|
-
$ sudo dnf install cargo
|
|
43
|
+
$ sudo dnf install cargo clang19 llvm19 lld19 cmake git golang libtool ninja-build pkg-config rustc ruby libatomic-static libstdc++-static sed unzip which libicu-devel 'perl(Math::BigInt)'
|
|
30
44
|
```
|
|
31
45
|
|
|
32
46
|
```bash openSUSE Tumbleweed
|
|
@@ -56,6 +70,46 @@ $ brew install bun
|
|
|
56
70
|
|
|
57
71
|
</CodeGroup>
|
|
58
72
|
|
|
73
|
+
### Optional: Install `sccache`
|
|
74
|
+
|
|
75
|
+
sccache is used to cache compilation artifacts, significantly speeding up builds. It must be installed with S3 support:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
# For macOS
|
|
79
|
+
$ brew install sccache
|
|
80
|
+
|
|
81
|
+
# For Linux. Note that the version in your package manager may not have S3 support.
|
|
82
|
+
$ cargo install sccache --features=s3
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
This will install `sccache` with S3 support. Our build scripts will automatically detect and use `sccache` with our shared S3 cache. **Note**: Not all versions of `sccache` are compiled with S3 support, hence we recommend installing it via `cargo`.
|
|
86
|
+
|
|
87
|
+
#### Registering AWS Credentials for `sccache` (Core Developers Only)
|
|
88
|
+
|
|
89
|
+
Core developers have write access to the shared S3 cache. To enable write access, you must log in with AWS credentials. The easiest way to do this is to use the [`aws` CLI](https://aws.amazon.com/cli/) and invoke [`aws configure` to provide your AWS security info](https://docs.aws.amazon.com/cli/latest/reference/configure/).
|
|
90
|
+
|
|
91
|
+
The `cmake` scripts should automatically detect your AWS credentials from the environment or the `~/.aws/credentials` file.
|
|
92
|
+
|
|
93
|
+
<details>
|
|
94
|
+
<summary>Logging in to the `aws` CLI</summary>
|
|
95
|
+
|
|
96
|
+
1. Install the AWS CLI by following [the official guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
|
|
97
|
+
2. Log in to your AWS account console. A team member should provide you with your credentials.
|
|
98
|
+
3. Click your name in the top right > Security credentials.
|
|
99
|
+
4. Scroll to "Access keys" and create a new access key.
|
|
100
|
+
5. Run `aws configure` in your terminal and provide the access key ID and secret access key when prompted.
|
|
101
|
+
|
|
102
|
+
</details>
|
|
103
|
+
|
|
104
|
+
<details>
|
|
105
|
+
<summary>Common Issues You May Encounter</summary>
|
|
106
|
+
|
|
107
|
+
- To confirm that the cache is being used, you can use the `sccache --show-stats` command right after a build. This will expose very useful statistics, including cache hits/misses.
|
|
108
|
+
- If you have multiple AWS profiles configured, ensure that the correct profile is set in the `AWS_PROFILE` environment variable.
|
|
109
|
+
- `sccache` follows a server-client model. If you run into weird issues where `sccache` refuses to use S3, even though you have AWS credentials configured, try killing any running `sccache` servers with `sccache --stop-server` and then re-running the build.
|
|
110
|
+
|
|
111
|
+
</details>
|
|
112
|
+
|
|
59
113
|
## Install LLVM
|
|
60
114
|
|
|
61
115
|
Bun requires LLVM 19 (`clang` is part of LLVM). This version requirement is to match WebKit (precompiled), as mismatching versions will cause memory allocation failures at runtime. In most cases, you can install LLVM through your system package manager:
|
|
@@ -156,7 +210,7 @@ Bun generally takes about 2.5 minutes to compile a debug build when there are Zi
|
|
|
156
210
|
- Batch up your changes
|
|
157
211
|
- Ensure zls is running with incremental watching for LSP errors (if you use VSCode and install Zig and run `bun run build` once to download Zig, this should just work)
|
|
158
212
|
- Prefer using the debugger ("CodeLLDB" in VSCode) to step through the code.
|
|
159
|
-
- Use debug logs. `BUN_DEBUG_<scope>=1` will enable debug logging for the corresponding `Output.scoped(.<scope>,
|
|
213
|
+
- Use debug logs. `BUN_DEBUG_<scope>=1` will enable debug logging for the corresponding `Output.scoped(.<scope>, .hidden)` logs. You can also set `BUN_DEBUG_QUIET_LOGS=1` to disable all debug logging that isn't explicitly enabled. To dump debug logs into a file, `BUN_DEBUG=<path-to-file>.log`. Debug logs are aggressively removed in release builds.
|
|
160
214
|
- src/js/\*\*.ts changes are pretty much instant to rebuild. C++ changes are a bit slower, but still much faster than the Zig code (Zig is one compilation unit, C++ is many).
|
|
161
215
|
|
|
162
216
|
## Code generation scripts
|
|
@@ -327,15 +381,6 @@ bun run build -DUSE_STATIC_LIBATOMIC=OFF
|
|
|
327
381
|
|
|
328
382
|
The built version of Bun may not work on other systems if compiled this way.
|
|
329
383
|
|
|
330
|
-
### ccache conflicts with building TinyCC on macOS
|
|
331
|
-
|
|
332
|
-
If you run into issues with `ccache` when building TinyCC, try reinstalling ccache
|
|
333
|
-
|
|
334
|
-
```bash
|
|
335
|
-
brew uninstall ccache
|
|
336
|
-
brew install ccache
|
|
337
|
-
```
|
|
338
|
-
|
|
339
384
|
## Using bun-debug
|
|
340
385
|
|
|
341
386
|
- Disable logging: `BUN_DEBUG_QUIET_LOGS=1 bun-debug ...` (to disable all debug logging)
|
package/docs/quickstart.mdx
CHANGED
|
@@ -219,16 +219,21 @@ Build a minimal HTTP server with `Bun.serve`, run it locally, then evolve it by
|
|
|
219
219
|
|
|
220
220
|
Bun can also execute `"scripts"` from your `package.json`. Add the following script:
|
|
221
221
|
|
|
222
|
+
{/* prettier-ignore */}
|
|
222
223
|
```json package.json icon="file-code"
|
|
223
224
|
{
|
|
224
225
|
"name": "quickstart",
|
|
225
226
|
"module": "index.ts",
|
|
226
227
|
"type": "module",
|
|
227
|
-
"
|
|
228
|
-
|
|
229
|
-
|
|
228
|
+
"private": true,
|
|
229
|
+
"scripts": { // [!code ++]
|
|
230
|
+
"start": "bun run index.ts" // [!code ++]
|
|
231
|
+
}, // [!code ++]
|
|
230
232
|
"devDependencies": {
|
|
231
233
|
"@types/bun": "latest"
|
|
234
|
+
},
|
|
235
|
+
"peerDependencies": {
|
|
236
|
+
"typescript": "^5"
|
|
232
237
|
}
|
|
233
238
|
}
|
|
234
239
|
```
|
package/docs/runtime/bunfig.mdx
CHANGED
|
@@ -276,6 +276,58 @@ This is useful for catching flaky tests or non-deterministic behavior. Each test
|
|
|
276
276
|
|
|
277
277
|
The `--rerun-each` CLI flag will override this setting when specified.
|
|
278
278
|
|
|
279
|
+
### `test.concurrentTestGlob`
|
|
280
|
+
|
|
281
|
+
Specify a glob pattern to automatically run matching test files with concurrent test execution enabled. Test files matching this pattern will behave as if the `--concurrent` flag was passed, running all tests within those files concurrently.
|
|
282
|
+
|
|
283
|
+
```toml title="bunfig.toml" icon="settings"
|
|
284
|
+
[test]
|
|
285
|
+
concurrentTestGlob = "**/concurrent-*.test.ts"
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
This is useful for:
|
|
289
|
+
|
|
290
|
+
- Gradually migrating test suites to concurrent execution
|
|
291
|
+
- Running integration tests concurrently while keeping unit tests sequential
|
|
292
|
+
- Separating fast concurrent tests from tests that require sequential execution
|
|
293
|
+
|
|
294
|
+
The `--concurrent` CLI flag will override this setting when specified.
|
|
295
|
+
|
|
296
|
+
### `test.onlyFailures`
|
|
297
|
+
|
|
298
|
+
When enabled, only failed tests are displayed in the output. This helps reduce noise in large test suites by hiding passing tests. Default `false`.
|
|
299
|
+
|
|
300
|
+
```toml title="bunfig.toml" icon="settings"
|
|
301
|
+
[test]
|
|
302
|
+
onlyFailures = true
|
|
303
|
+
```
|
|
304
|
+
|
|
305
|
+
This is equivalent to using the `--only-failures` flag when running `bun test`.
|
|
306
|
+
|
|
307
|
+
### `test.reporter`
|
|
308
|
+
|
|
309
|
+
Configure the test reporter settings.
|
|
310
|
+
|
|
311
|
+
#### `test.reporter.dots`
|
|
312
|
+
|
|
313
|
+
Enable the dots reporter, which displays a compact output showing a dot for each test. Default `false`.
|
|
314
|
+
|
|
315
|
+
```toml title="bunfig.toml" icon="settings"
|
|
316
|
+
[test.reporter]
|
|
317
|
+
dots = true
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
#### `test.reporter.junit`
|
|
321
|
+
|
|
322
|
+
Enable JUnit XML reporting and specify the output file path.
|
|
323
|
+
|
|
324
|
+
```toml title="bunfig.toml" icon="settings"
|
|
325
|
+
[test.reporter]
|
|
326
|
+
junit = "test-results.xml"
|
|
327
|
+
```
|
|
328
|
+
|
|
329
|
+
This generates a JUnit XML report that can be consumed by CI systems and other tools.
|
|
330
|
+
|
|
279
331
|
## Package manager
|
|
280
332
|
|
|
281
333
|
Package management is a complex issue; to support a range of use cases, the behavior of `bun install` can be configured under the `[install]` section.
|
|
@@ -551,7 +603,7 @@ For more details see [Minimum release age](/pm/cli/install#minimum-release-age)
|
|
|
551
603
|
|
|
552
604
|
The `bun run` command can be configured under the `[run]` section. These apply to the `bun run` command and the `bun` command when running a file or executable or script.
|
|
553
605
|
|
|
554
|
-
Currently, `bunfig.toml`
|
|
606
|
+
Currently, `bunfig.toml` is only automatically loaded for `bun run` in a local project (it doesn't check for a global `.bunfig.toml`).
|
|
555
607
|
|
|
556
608
|
### `run.shell` - use the system shell or Bun's shell
|
|
557
609
|
|
|
@@ -46,29 +46,22 @@ console.log(result);
|
|
|
46
46
|
|
|
47
47
|
This replaces all images with a thumbnail of Rick Astley and wraps each `<img>` in a link, producing a diff like this:
|
|
48
48
|
|
|
49
|
+
{/* prettier-ignore */}
|
|
49
50
|
```html
|
|
50
51
|
<html>
|
|
51
52
|
<body>
|
|
52
|
-
<img src="/cat.jpg" />
|
|
53
|
-
<img src="
|
|
54
|
-
<
|
|
55
|
-
|
|
56
|
-
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
|
|
63
|
-
|
|
64
|
-
</a>
|
|
65
|
-
// [!code ++]
|
|
66
|
-
<a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank">
|
|
67
|
-
// [!code ++]
|
|
68
|
-
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" />
|
|
69
|
-
// [!code ++]
|
|
70
|
-
</a>
|
|
71
|
-
// [!code ++]
|
|
53
|
+
<img src="/cat.jpg" /> <!-- [!code --] -->
|
|
54
|
+
<img src="dog.png" /> <!-- [!code --] -->
|
|
55
|
+
<img src="https://example.com/bird.webp" /> <!-- [!code --] -->
|
|
56
|
+
<a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
|
|
57
|
+
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
|
|
58
|
+
</a> <!-- [!code ++] -->
|
|
59
|
+
<a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
|
|
60
|
+
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
|
|
61
|
+
</a> <!-- [!code ++] -->
|
|
62
|
+
<a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" target="_blank"> <!-- [!code ++] -->
|
|
63
|
+
<img src="https://img.youtube.com/vi/dQw4w9WgXcQ/maxresdefault.jpg" alt="Definitely not a rickroll" /> <!-- [!code ++] -->
|
|
64
|
+
</a> <!-- [!code ++] -->
|
|
72
65
|
</body>
|
|
73
66
|
</html>
|
|
74
67
|
```
|
|
@@ -283,7 +283,7 @@ You can also access the `Server` object from the `fetch` handler. It's the secon
|
|
|
283
283
|
const server = Bun.serve({
|
|
284
284
|
fetch(req, server) {
|
|
285
285
|
const ip = server.requestIP(req);
|
|
286
|
-
return new Response(`Your IP is ${ip}`);
|
|
286
|
+
return new Response(`Your IP is ${ip.address}`);
|
|
287
287
|
},
|
|
288
288
|
});
|
|
289
289
|
```
|
|
@@ -107,13 +107,13 @@ Bun.serve({
|
|
|
107
107
|
|
|
108
108
|
Once the upgrade succeeds, Bun will send a `101 Switching Protocols` response per the [spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism). Additional `headers` can be attached to this `Response` in the call to `server.upgrade()`.
|
|
109
109
|
|
|
110
|
+
{/* prettier-ignore */}
|
|
110
111
|
```ts server.ts icon="/icons/typescript.svg"
|
|
111
112
|
Bun.serve({
|
|
112
113
|
fetch(req, server) {
|
|
113
114
|
const sessionId = await generateSessionId();
|
|
114
115
|
server.upgrade(req, {
|
|
115
|
-
headers: {
|
|
116
|
-
// [!code ++]
|
|
116
|
+
headers: { // [!code ++]
|
|
117
117
|
"Set-Cookie": `SessionId=${sessionId}`, // [!code ++]
|
|
118
118
|
}, // [!code ++]
|
|
119
119
|
});
|
|
@@ -126,6 +126,8 @@ Bun.serve({
|
|
|
126
126
|
|
|
127
127
|
Contextual `data` can be attached to a new WebSocket in the `.upgrade()` call. This data is made available on the `ws.data` property inside the WebSocket handlers.
|
|
128
128
|
|
|
129
|
+
To strongly type `ws.data`, add a `data` property to the `websocket` handler object. This types `ws.data` across all lifecycle hooks.
|
|
130
|
+
|
|
129
131
|
```ts server.ts icon="/icons/typescript.svg"
|
|
130
132
|
type WebSocketData = {
|
|
131
133
|
createdAt: number;
|
|
@@ -166,6 +168,10 @@ Bun.serve({
|
|
|
166
168
|
});
|
|
167
169
|
```
|
|
168
170
|
|
|
171
|
+
<Info>
|
|
172
|
+
**Note:** Previously, you could specify the type of `ws.data` using a type parameter on `Bun.serve`, like `Bun.serve<MyData>({...})`. This pattern was removed due to [a limitation in TypeScript](https://github.com/microsoft/TypeScript/issues/26242) in favor of the `data` property shown above.
|
|
173
|
+
</Info>
|
|
174
|
+
|
|
169
175
|
To connect to this server from the browser, create a new `WebSocket`.
|
|
170
176
|
|
|
171
177
|
```ts browser.js icon="file-code"
|
|
@@ -183,6 +183,29 @@ import { stuff } from "foo";
|
|
|
183
183
|
|
|
184
184
|
The full specification of this algorithm are officially documented in the [Node.js documentation](https://nodejs.org/api/modules.html); we won't rehash it here. Briefly: if you import `from "foo"`, Bun scans up the file system for a `node_modules` directory containing the package `foo`.
|
|
185
185
|
|
|
186
|
+
### NODE_PATH
|
|
187
|
+
|
|
188
|
+
Bun supports `NODE_PATH` for additional module resolution directories:
|
|
189
|
+
|
|
190
|
+
```bash
|
|
191
|
+
NODE_PATH=./packages bun run src/index.js
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
```ts
|
|
195
|
+
// packages/foo/index.js
|
|
196
|
+
export const hello = "world";
|
|
197
|
+
|
|
198
|
+
// src/index.js
|
|
199
|
+
import { hello } from "foo";
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
Multiple paths use the platform's delimiter (`:` on Unix, `;` on Windows):
|
|
203
|
+
|
|
204
|
+
```bash
|
|
205
|
+
NODE_PATH=./packages:./lib bun run src/index.js # Unix/macOS
|
|
206
|
+
NODE_PATH=./packages;./lib bun run src/index.js # Windows
|
|
207
|
+
```
|
|
208
|
+
|
|
186
209
|
Once it finds the `foo` package, Bun reads the `package.json` to determine how the package should be imported. To determine the package's entrypoint, Bun first reads the `exports` field and checks for the following conditions.
|
|
187
210
|
|
|
188
211
|
```json package.json icon="file-json"
|
package/docs/runtime/redis.mdx
CHANGED
|
@@ -51,6 +51,7 @@ await client.incr("counter");
|
|
|
51
51
|
By default, the client reads connection information from the following environment variables (in order of precedence):
|
|
52
52
|
|
|
53
53
|
- `REDIS_URL`
|
|
54
|
+
- `VALKEY_URL`
|
|
54
55
|
- If not set, defaults to `"redis://localhost:6379"`
|
|
55
56
|
|
|
56
57
|
### Connection Lifecycle
|
package/docs/runtime/utils.mdx
CHANGED
|
@@ -234,8 +234,8 @@ Bun.openInEditor(currentFile);
|
|
|
234
234
|
You can override this via the `debug.editor` setting in your [`bunfig.toml`](/runtime/bunfig).
|
|
235
235
|
|
|
236
236
|
```toml bunfig.toml
|
|
237
|
-
[debug]
|
|
238
|
-
editor = "code"
|
|
237
|
+
[debug] # [!code ++]
|
|
238
|
+
editor = "code" # [!code ++]
|
|
239
239
|
```
|
|
240
240
|
|
|
241
241
|
Or specify an editor with the `editor` param. You can also specify a line and column number.
|
|
@@ -184,6 +184,53 @@ This is useful for:
|
|
|
184
184
|
- Large test suites that consume significant memory
|
|
185
185
|
- Development environments with memory constraints
|
|
186
186
|
|
|
187
|
+
## Test execution
|
|
188
|
+
|
|
189
|
+
### concurrentTestGlob
|
|
190
|
+
|
|
191
|
+
Automatically run test files matching a glob pattern with concurrent test execution enabled. This is useful for gradually migrating test suites to concurrent execution or for running specific test types concurrently.
|
|
192
|
+
|
|
193
|
+
```toml title="bunfig.toml" icon="settings"
|
|
194
|
+
[test]
|
|
195
|
+
concurrentTestGlob = "**/concurrent-*.test.ts" # Run files matching this pattern concurrently
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
Test files matching this pattern will behave as if the `--concurrent` flag was passed, running all tests within those files concurrently. This allows you to:
|
|
199
|
+
|
|
200
|
+
- Gradually migrate your test suite to concurrent execution
|
|
201
|
+
- Run integration tests concurrently while keeping unit tests sequential
|
|
202
|
+
- Separate fast concurrent tests from tests that require sequential execution
|
|
203
|
+
|
|
204
|
+
The `--concurrent` CLI flag will override this setting when specified, forcing all tests to run concurrently regardless of the glob pattern.
|
|
205
|
+
|
|
206
|
+
#### randomize
|
|
207
|
+
|
|
208
|
+
Run tests in random order to identify tests with hidden dependencies:
|
|
209
|
+
|
|
210
|
+
```toml title="bunfig.toml" icon="settings"
|
|
211
|
+
[test]
|
|
212
|
+
randomize = true
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
#### seed
|
|
216
|
+
|
|
217
|
+
Specify a seed for reproducible random test order. Requires `randomize = true`:
|
|
218
|
+
|
|
219
|
+
```toml title="bunfig.toml" icon="settings"
|
|
220
|
+
[test]
|
|
221
|
+
randomize = true
|
|
222
|
+
seed = 2444615283
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
#### rerunEach
|
|
226
|
+
|
|
227
|
+
Re-run each test file multiple times to identify flaky tests:
|
|
228
|
+
|
|
229
|
+
```toml title="bunfig.toml" icon="settings"
|
|
230
|
+
[test]
|
|
231
|
+
rerunEach = 3
|
|
232
|
+
```
|
|
233
|
+
|
|
187
234
|
## Coverage Options
|
|
188
235
|
|
|
189
236
|
### Basic Coverage Settings
|
package/docs/test/reporters.mdx
CHANGED
|
@@ -41,6 +41,15 @@ test/package-json-lint.test.ts:
|
|
|
41
41
|
Ran 4 tests across 1 files. [0.66ms]
|
|
42
42
|
```
|
|
43
43
|
|
|
44
|
+
### Dots Reporter
|
|
45
|
+
|
|
46
|
+
The dots reporter shows `.` for passing tests and `F` for failures—useful for large test suites.
|
|
47
|
+
|
|
48
|
+
```sh terminal icon="terminal"
|
|
49
|
+
bun test --dots
|
|
50
|
+
bun test --reporter=dots
|
|
51
|
+
```
|
|
52
|
+
|
|
44
53
|
### JUnit XML Reporter
|
|
45
54
|
|
|
46
55
|
For CI/CD environments, Bun supports generating JUnit XML reports. JUnit XML is a widely-adopted format for test results that can be parsed by many CI/CD systems, including GitLab, Jenkins, and others.
|
package/package.json
CHANGED