bun-types 1.2.19-canary.20250709T140635 → 1.2.19-canary.20250711T140648

package/README.md

@@ -1,7 +1,7 @@
 # TypeScript types for Bun
 
 <p align="center">
-  <a href="https://bun.sh"><img src="https://bun.sh/logo@2x.png" alt="Logo"></a>
+  <a href="https://bun.com"><img src="https://bun.com/logo@2x.png" alt="Logo"></a>
 </p>
 
 These are the type definitions for Bun's JavaScript runtime APIs.

package/bun.d.ts

@@ -2334,7 +2334,7 @@ declare module "bun" {
   }
 
   /**
-   * @see [Bun.build API docs](https://bun.sh/docs/bundler#api)
+   * @see [Bun.build API docs](https://bun.com/docs/bundler#api)
    */
   interface BuildConfig {
     entrypoints: string[]; // list of file path
@@ -2519,7 +2519,7 @@ declare module "bun" {
    *
    * These are fast APIs that can run in a worker thread if used asynchronously.
    *
-   * @see [Bun.password API docs](https://bun.sh/guides/util/hash-a-password)
+   * @see [Bun.password API docs](https://bun.com/guides/util/hash-a-password)
    *
    * @category Security
    */
@@ -2555,7 +2555,7 @@ declare module "bun" {
    * Password hashing functions are necessarily slow, and this object will
    * automatically run in a worker thread.
    *
-   * @see [Bun.password API docs](https://bun.sh/guides/util/hash-a-password)
+   * @see [Bun.password API docs](https://bun.com/guides/util/hash-a-password)
    *
    * The underlying implementation of these functions are provided by the Zig
    * Standard Library. Thanks to \@jedisct1 and other Zig contributors for their
@@ -3510,7 +3510,13 @@ declare module "bun" {
       [K in HTTPMethod]?: RouteHandlerWithWebSocketUpgrade<T>;
     };
 
-    type RouteValue<T extends string> = Response | false | RouteHandler<T> | RouteHandlerObject<T> | HTMLBundle;
+    type RouteValue<T extends string> =
+      | Response
+      | false
+      | RouteHandler<T>
+      | RouteHandlerObject<T>
+      | HTMLBundle
+      | BunFile;
     type RouteValueWithWebSocketUpgrade<T extends string> =
       | RouteValue<T>
       | RouteHandlerWithWebSocketUpgrade<T>
@@ -5713,7 +5719,7 @@ declare module "bun" {
      */
     | "browser";
 
-  /** https://bun.sh/docs/bundler/loaders */
+  /** https://bun.com/docs/bundler/loaders */
   type Loader = "js" | "jsx" | "ts" | "tsx" | "json" | "toml" | "file" | "napi" | "wasm" | "text" | "css" | "html";
 
   interface PluginConstraints {
@@ -7975,15 +7981,15 @@ declare module "bun" {
     workspaces: {
       [workspace: string]: BunLockFileWorkspacePackage;
     };
-    /** @see https://bun.sh/docs/install/overrides */
+    /** @see https://bun.com/docs/install/overrides */
     overrides?: Record<string, string>;
-    /** @see https://bun.sh/docs/install/patch */
+    /** @see https://bun.com/docs/install/patch */
     patchedDependencies?: Record<string, string>;
-    /** @see https://bun.sh/docs/install/lifecycle#trusteddependencies */
+    /** @see https://bun.com/docs/install/lifecycle#trusteddependencies */
     trustedDependencies?: string[];
-    /** @see https://bun.sh/docs/install/catalogs */
+    /** @see https://bun.com/docs/install/catalogs */
     catalog?: Record<string, string>;
-    /** @see https://bun.sh/docs/install/catalogs */
+    /** @see https://bun.com/docs/install/catalogs */
     catalogs?: Record<string, Record<string, string>>;
 
     /**

package/devserver.d.ts

@@ -29,7 +29,7 @@ interface ImportMeta {
    * However, this check is usually not needed as Bun will dead-code-eliminate
    * calls to all of the HMR APIs in production builds.
    *
-   * https://bun.sh/docs/bundler/hmr
+   * https://bun.com/docs/bundler/hmr
    */
   hot: {
     /**
@@ -167,7 +167,7 @@ interface ImportMeta {
      *
      * For compatibility with Vite, event names are also available via vite:* prefix instead of bun:*.
      *
-     * https://bun.sh/docs/bundler/hmr#import-meta-hot-on-and-off
+     * https://bun.com/docs/bundler/hmr#import-meta-hot-on-and-off
      * @param event The event to listen to
      * @param callback The callback to call when the event is emitted
      */
@@ -178,7 +178,7 @@ interface ImportMeta {
      *
      * For compatibility with Vite, event names are also available via vite:* prefix instead of bun:*.
      *
-     * https://bun.sh/docs/bundler/hmr#import-meta-hot-on-and-off
+     * https://bun.com/docs/bundler/hmr#import-meta-hot-on-and-off
      * @param event The event to stop listening to
      * @param callback The callback to stop listening to
      */

package/docs/api/binary-data.md

@@ -522,7 +522,7 @@ for await (const chunk of stream) {
 }
 ```
 
-For a more complete discussion of streams in Bun, see [API > Streams](https://bun.sh/docs/api/streams).
+For a more complete discussion of streams in Bun, see [API > Streams](https://bun.com/docs/api/streams).
 
 ## Conversion
 

package/docs/api/cc.md

@@ -2,7 +2,7 @@
 
 ## Usage (cc in `bun:ffi`)
 
-See the [introduction blog post](https://bun.sh/blog/compile-and-run-c-in-js) for more information.
+See the [introduction blog post](https://bun.com/blog/compile-and-run-c-in-js) for more information.
 
 JavaScript:
 

package/docs/api/dns.md

@@ -3,7 +3,7 @@ Bun implements the `node:dns` module.
 ```ts
 import * as dns from "node:dns";
 
-const addrs = await dns.promises.resolve4("bun.sh", { ttl: true });
+const addrs = await dns.promises.resolve4("bun.com", { ttl: true });
 console.log(addrs);
 // => [{ address: "172.67.161.226", family: 4, ttl: 0 }, ...]
 ```
@@ -54,10 +54,10 @@ Here's an example:
 ```ts
 import { dns } from "bun";
 
-dns.prefetch("bun.sh", 443);
+dns.prefetch("bun.com", 443);
 //
 // ... sometime later ...
-await fetch("https://bun.sh");
+await fetch("https://bun.com");
 ```
 
 ### `dns.getCacheStats()`

package/docs/api/fetch.md

@@ -267,7 +267,7 @@ const response = await fetch("s3://my-bucket/path/to/object", {
 
 Note: Only PUT and POST methods support request bodies when using S3. For uploads, Bun automatically uses multipart upload for streaming bodies.
 
-You can read more about Bun's S3 support in the [S3](https://bun.sh/docs/api/s3) documentation.
+You can read more about Bun's S3 support in the [S3](https://bun.com/docs/api/s3) documentation.
 
 #### File URLs - `file://`
 
@@ -337,7 +337,7 @@ This will print the request and response headers to your terminal:
 ```sh
 [fetch] > HTTP/1.1 GET http://example.com/
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.19-canary.20250709T140635
+[fetch] > User-Agent: Bun/1.2.19-canary.20250711T140648
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br
@@ -376,14 +376,14 @@ To prefetch a DNS entry, you can use the `dns.prefetch` API. This API is useful
 ```ts
 import { dns } from "bun";
 
-dns.prefetch("bun.sh");
+dns.prefetch("bun.com");
 ```
 
 #### DNS caching
 
 By default, Bun caches and deduplicates DNS queries in-memory for up to 30 seconds. You can see the cache stats by calling `dns.getCacheStats()`:
 
-To learn more about DNS caching in Bun, see the [DNS caching](https://bun.sh/docs/api/dns) documentation.
+To learn more about DNS caching in Bun, see the [DNS caching](https://bun.com/docs/api/dns) documentation.
 
 ### Preconnect to a host
 
@@ -392,7 +392,7 @@ To preconnect to a host, you can use the `fetch.preconnect` API. This API is use
 ```ts
 import { fetch } from "bun";
 
-fetch.preconnect("https://bun.sh");
+fetch.preconnect("https://bun.com");
 ```
 
 Note: calling `fetch` immediately after `fetch.preconnect` will not make your request faster. Preconnecting only helps if you know you'll need to connect to a host soon, but you're not ready to make the request yet.
@@ -402,7 +402,7 @@ Note: calling `fetch` immediately after `fetch.preconnect` will not make your re
 To preconnect to a host at startup, you can pass `--fetch-preconnect`:
 
 ```sh
-$ bun --fetch-preconnect https://bun.sh ./my-script.ts
+$ bun --fetch-preconnect https://bun.com ./my-script.ts
 ```
 
 This is sort of like `<link rel="preconnect">` in HTML.

package/docs/api/file-io.md

@@ -1,8 +1,8 @@
 {% callout %}
 
-<!-- **Note** — The `Bun.file` and `Bun.write` APIs documented on this page are heavily optimized and represent the recommended way to perform file-system tasks using Bun. Existing Node.js projects may use Bun's [nearly complete](https://bun.sh/docs/runtime/nodejs-apis#node-fs) implementation of the [`node:fs`](https://nodejs.org/api/fs.html) module. -->
+<!-- **Note** — The `Bun.file` and `Bun.write` APIs documented on this page are heavily optimized and represent the recommended way to perform file-system tasks using Bun. Existing Node.js projects may use Bun's [nearly complete](https://bun.com/docs/runtime/nodejs-apis#node-fs) implementation of the [`node:fs`](https://nodejs.org/api/fs.html) module. -->
 
-**Note** — The `Bun.file` and `Bun.write` APIs documented on this page are heavily optimized and represent the recommended way to perform file-system tasks using Bun. For operations that are not yet available with `Bun.file`, such as `mkdir` or `readdir`, you can use Bun's [nearly complete](https://bun.sh/docs/runtime/nodejs-apis#node-fs) implementation of the [`node:fs`](https://nodejs.org/api/fs.html) module.
+**Note** — The `Bun.file` and `Bun.write` APIs documented on this page are heavily optimized and represent the recommended way to perform file-system tasks using Bun. For operations that are not yet available with `Bun.file`, such as `mkdir` or `readdir`, you can use Bun's [nearly complete](https://bun.com/docs/runtime/nodejs-apis#node-fs) implementation of the [`node:fs`](https://nodejs.org/api/fs.html) module.
 
 {% /callout %}
 
@@ -208,7 +208,7 @@ await Bun.write(Bun.stdout, input);
 To write the body of an HTTP response to disk:
 
 ```ts
-const response = await fetch("https://bun.sh");
+const response = await fetch("https://bun.com");
 await Bun.write("index.html", response);
 ```
 

package/docs/api/globals.md

@@ -34,7 +34,7 @@ Bun implements the following globals.
 
 - [`Buffer`](https://nodejs.org/api/buffer.html#class-buffer)
 - Node.js
-- See [Node.js > `Buffer`](https://bun.sh/docs/runtime/nodejs-apis#node-buffer)
+- See [Node.js > `Buffer`](https://bun.com/docs/runtime/nodejs-apis#node-buffer)
 
 ---
 
@@ -172,7 +172,7 @@ Bun implements the following globals.
 
 - [`global`](https://nodejs.org/api/globals.html#global)
 - Node.js
-- See [Node.js > `global`](https://bun.sh/docs/runtime/nodejs-apis#global).
+- See [Node.js > `global`](https://bun.com/docs/runtime/nodejs-apis#global).
 
 ---
 
@@ -188,7 +188,7 @@ Bun implements the following globals.
 
 ---
 
-- [`HTMLRewriter`](https://bun.sh/docs/api/html-rewriter)
+- [`HTMLRewriter`](https://bun.com/docs/api/html-rewriter)
 - Cloudflare
 -  
 
@@ -220,7 +220,7 @@ Bun implements the following globals.
 
 - [`process`](https://nodejs.org/api/process.html)
 - Node.js
-- See [Node.js > `process`](https://bun.sh/docs/runtime/nodejs-apis#node-process)
+- See [Node.js > `process`](https://bun.com/docs/runtime/nodejs-apis#node-process)
 
 ---
 

package/docs/api/http.md

@@ -1,7 +1,7 @@
 The page primarily documents the Bun-native `Bun.serve` API. Bun also implements [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) and the Node.js [`http`](https://nodejs.org/api/http.html) and [`https`](https://nodejs.org/api/https.html) modules.
 
 {% callout %}
-These modules have been re-implemented to use Bun's fast internal HTTP infrastructure. Feel free to use these modules directly; frameworks like [Express](https://expressjs.com/) that depend on these modules should work out of the box. For granular compatibility information, see [Runtime > Node.js APIs](https://bun.sh/docs/runtime/nodejs-apis).
+These modules have been re-implemented to use Bun's fast internal HTTP infrastructure. Feel free to use these modules directly; frameworks like [Express](https://expressjs.com/) that depend on these modules should work out of the box. For granular compatibility information, see [Runtime > Node.js APIs](https://bun.com/docs/runtime/nodejs-apis).
 {% /callout %}
 
 To start a high-performance HTTP server with a clean API, the recommended approach is [`Bun.serve`](#start-a-server-bun-serve).
@@ -149,7 +149,7 @@ Bun.serve({
     }),
 
     // Redirects
-    "/blog": Response.redirect("https://bun.sh/blog"),
+    "/blog": Response.redirect("https://bun.com/blog"),
 
     // API responses
     "/api/config": Response.json({
@@ -342,9 +342,9 @@ Bun.serve({
 });
 ```
 
-HTML imports don't just serve HTML — it's a full-featured frontend bundler, transpiler, and toolkit built using Bun's [bundler](https://bun.sh/docs/bundler), JavaScript transpiler and CSS parser. You can use this to build full-featured frontends with React, TypeScript, Tailwind CSS, and more.
+HTML imports don't just serve HTML — it's a full-featured frontend bundler, transpiler, and toolkit built using Bun's [bundler](https://bun.com/docs/bundler), JavaScript transpiler and CSS parser. You can use this to build full-featured frontends with React, TypeScript, Tailwind CSS, and more.
 
-For a complete guide on building full-stack applications with HTML imports, including detailed examples and best practices, see [/docs/bundler/fullstack](https://bun.sh/docs/bundler/fullstack).
+For a complete guide on building full-stack applications with HTML imports, including detailed examples and best practices, see [/docs/bundler/fullstack](https://bun.com/docs/bundler/fullstack).
 
 ### Practical example: REST API
 
@@ -605,7 +605,7 @@ Bun.serve({
 ```
 
 {% callout %}
-[Learn more about debugging in Bun](https://bun.sh/docs/runtime/debugger)
+[Learn more about debugging in Bun](https://bun.com/docs/runtime/debugger)
 {% /callout %}
 
 The call to `Bun.serve` returns a `Server` object. To stop the server, call the `.stop()` method.
@@ -772,7 +772,7 @@ Instead of passing the server options into `Bun.serve`, `export default` it. Thi
 $ bun --hot server.ts
 ``` -->
 
-<!-- It's possible to configure hot reloading while using the explicit `Bun.serve` API; for details refer to [Runtime > Hot reloading](https://bun.sh/docs/runtime/hot). -->
+<!-- It's possible to configure hot reloading while using the explicit `Bun.serve` API; for details refer to [Runtime > Hot reloading](https://bun.com/docs/runtime/hot). -->
 
 ## Streaming files
 

package/docs/api/s3.md

@@ -4,7 +4,7 @@ Production servers often read, upload, and write files to S3-compatible object s
 
 ### Bun's S3 API is fast
 
-{% image src="https://bun.sh/bun-s3-node.gif" alt="Bun's S3 API is fast" caption="Left: Bun v1.1.44. Right: Node.js v23.6.0" /%}
+{% image src="https://bun.com/bun-s3-node.gif" alt="Bun's S3 API is fast" caption="Left: Bun v1.1.44. Right: Node.js v23.6.0" /%}
 
 {% /callout %}
 

package/docs/api/spawn.md

@@ -140,7 +140,7 @@ You can read results from the subprocess via the `stdout` and `stderr` propertie
 ```ts
 const proc = Bun.spawn(["bun", "--version"]);
 const text = await proc.stdout.text();
-console.log(text); // => "1.2.19-canary.20250709T140635\n"
+console.log(text); // => "1.2.19-canary.20250711T140648\n"
 ```
 
 Configure the output stream by passing one of the following values to `stdout/stderr`:

package/docs/api/utils.md

@@ -234,7 +234,7 @@ const currentFile = import.meta.url;
 Bun.openInEditor(currentFile);
 ```
 
-You can override this via the `debug.editor` setting in your [`bunfig.toml`](https://bun.sh/docs/runtime/bunfig).
+You can override this via the `debug.editor` setting in your [`bunfig.toml`](https://bun.com/docs/runtime/bunfig).
 
 ```toml-diff#bunfig.toml
 + [debug]
@@ -704,7 +704,7 @@ Bun.nanoseconds();
 Bun implements a set of convenience functions for asynchronously consuming the body of a `ReadableStream` and converting it to various binary formats.
 
 ```ts
-const stream = (await fetch("https://bun.sh")).body;
+const stream = (await fetch("https://bun.com")).body;
 stream; // => ReadableStream
 
 await Bun.readableStreamToArrayBuffer(stream);
@@ -787,7 +787,7 @@ const buffer = Buffer.alloc(1024 * 1024);
 estimateShallowMemoryUsageOf(buffer);
 // => 1048624
 
-const req = new Request("https://bun.sh");
+const req = new Request("https://bun.com");
 estimateShallowMemoryUsageOf(req);
 // => 167
 

package/docs/bundler/executables.md

@@ -126,6 +126,42 @@ The `--sourcemap` argument embeds a sourcemap compressed with zstd, so that erro
 
 The `--bytecode` argument enables bytecode compilation. Every time you run JavaScript code in Bun, JavaScriptCore (the engine) will compile your source code into bytecode. We can move this parsing work from runtime to bundle time, saving you startup time.
 
+## Act as the Bun CLI
+
+{% note %}
+
+New in Bun v1.2.16
+
+{% /note %}
+
+You can run a standalone executable as if it were the `bun` CLI itself by setting the `BUN_BE_BUN=1` environment variable. When this variable is set, the executable will ignore its bundled entrypoint and instead expose all the features of Bun's CLI.
+
+For example, consider an executable compiled from a simple script:
+
+```sh
+$ cat such-bun.js
+console.log("you shouldn't see this");
+
+$ bun build --compile ./such-bun.js
+ [3ms] bundle 1 modules
+[89ms] compile such-bun
+```
+
+Normally, running `./such-bun` with arguments would execute the script. However, with the `BUN_BE_BUN=1` environment variable, it acts just like the `bun` binary:
+
+```sh
+# Executable runs its own entrypoint by default
+$ ./such-bun install
+you shouldn't see this
+
+# With the env var, the executable acts like the `bun` CLI
+$ BUN_BE_BUN=1 ./such-bun install
+bun install v1.2.16-canary.1 (1d1db811)
+Checked 63 installs across 64 packages (no changes) [5.00ms]
+```
+
+This is useful for building CLI tools on top of Bun that may need to install packages, bundle dependencies, run different or local files and more without needing to download a separate binary or install bun.
+
 ## Full-stack executables
 
 {% note %}

package/docs/bundler/fullstack.md

@@ -325,7 +325,7 @@ When adding a build step is too complicated, you can set `development: false` in
 
 ## Plugins
 
-Bun's [bundler plugins](https://bun.sh/docs/bundler/plugins) are also supported when bundling static routes.
+Bun's [bundler plugins](https://bun.com/docs/bundler/plugins) are also supported when bundling static routes.
 
 To configure plugins for `Bun.serve`, add a `plugins` array in the `[serve.static]` section of your `bunfig.toml`.
 
@@ -365,7 +365,7 @@ Or in your CSS:
 
 ### Custom plugins
 
-Any JS file or module which exports a [valid bundler plugin object](https://bun.sh/docs/bundler/plugins#usage) (essentially an object with a `name` and `setup` field) can be placed inside the `plugins` array:
+Any JS file or module which exports a [valid bundler plugin object](https://bun.com/docs/bundler/plugins#usage) (essentially an object with a `name` and `setup` field) can be placed inside the `plugins` array:
 
 ```toml#bunfig.toml
 [serve.static]

package/docs/bundler/index.md

@@ -147,7 +147,7 @@ $ bun build ./index.tsx --outdir ./out --watch
 
 ## Content types
 
-Like the Bun runtime, the bundler supports an array of file types out of the box. The following table breaks down the bundler's set of standard "loaders". Refer to [Bundler > File types](https://bun.sh/docs/runtime/loaders) for full documentation.
+Like the Bun runtime, the bundler supports an array of file types out of the box. The following table breaks down the bundler's set of standard "loaders". Refer to [Bundler > File types](https://bun.com/docs/runtime/loaders) for full documentation.
 
 {% table %}
 
@@ -220,11 +220,11 @@ console.log(logo);
 The exact behavior of the file loader is also impacted by [`naming`](#naming) and [`publicPath`](#publicpath).
 {% /callout %}
 
-Refer to the [Bundler > Loaders](https://bun.sh/docs/bundler/loaders#file) page for more complete documentation on the file loader.
+Refer to the [Bundler > Loaders](https://bun.com/docs/bundler/loaders#file) page for more complete documentation on the file loader.
 
 ### Plugins
 
-The behavior described in this table can be overridden or extended with [plugins](https://bun.sh/docs/bundler/plugins). Refer to the [Bundler > Loaders](https://bun.sh/docs/bundler/plugins) page for complete documentation.
+The behavior described in this table can be overridden or extended with [plugins](https://bun.com/docs/bundler/plugins). Refer to the [Bundler > Loaders](https://bun.com/docs/bundler/plugins) page for complete documentation.
 
 ## API
 
@@ -484,7 +484,7 @@ n/a
 
 {% /codetabs %}
 
-Bun implements a universal plugin system for both Bun's runtime and bundler. Refer to the [plugin documentation](https://bun.sh/docs/bundler/plugins) for complete documentation.
+Bun implements a universal plugin system for both Bun's runtime and bundler. Refer to the [plugin documentation](https://bun.com/docs/bundler/plugins) for complete documentation.
 
 <!-- ### `manifest`
 
@@ -1102,7 +1102,7 @@ A prefix to be appended to any import paths in bundled code.
 
 In many cases, generated bundles will contain no `import` statements. After all, the goal of bundling is to combine all of the code into a single file. However there are a number of cases with the generated bundles will contain `import` statements.
 
-- **Asset imports** — When importing an unrecognized file type like `*.svg`, the bundler defers to the [`file` loader](https://bun.sh/docs/bundler/loaders#file), which copies the file into `outdir` as is. The import is converted into a variable
+- **Asset imports** — When importing an unrecognized file type like `*.svg`, the bundler defers to the [`file` loader](https://bun.com/docs/bundler/loaders#file), which copies the file into `outdir` as is. The import is converted into a variable
 - **External modules** — Files and modules can be marked as [`external`](#external), in which case they will not be included in the bundle. Instead, the `import` statement will be left in the final bundle.
 - **Chunking**. When [`splitting`](#splitting) is enabled, the bundler may generate separate "chunk" files that represent code that is shared among multiple entrypoints.
 
@@ -1178,7 +1178,7 @@ $ bun build ./index.tsx --outdir ./out --define 'STRING="value"' --define "neste
 
 ### `loader`
 
-A map of file extensions to [built-in loader names](https://bun.sh/docs/bundler/loaders#built-in-loaders). This can be used to quickly customize how certain files are loaded.
+A map of file extensions to [built-in loader names](https://bun.com/docs/bundler/loaders#built-in-loaders). This can be used to quickly customize how certain files are loaded.
 
 {% codetabs %}
 
@@ -1310,7 +1310,7 @@ Each artifact also contains the following properties:
 ---
 
 - `loader`
-- The loader was used to interpret the file. See [Bundler > Loaders](https://bun.sh/docs/bundler/loaders) to see how Bun maps file extensions to the appropriate built-in loader.
+- The loader was used to interpret the file. See [Bundler > Loaders](https://bun.com/docs/bundler/loaders) to see how Bun maps file extensions to the appropriate built-in loader.
 
 ---
 
@@ -1394,7 +1394,7 @@ $ bun build ./cli.tsx --outfile mycli --compile
 $ ./mycli
 ```
 
-Refer to [Bundler > Executables](https://bun.sh/docs/bundler/executables) for complete documentation.
+Refer to [Bundler > Executables](https://bun.com/docs/bundler/executables) for complete documentation.
 
 ## Logs and errors
 

package/docs/bundler/loaders.md

@@ -2,7 +2,7 @@ The Bun bundler implements a set of default loaders out of the box. As a rule of
 
 `.js` `.cjs` `.mjs` `.mts` `.cts` `.ts` `.tsx` `.jsx` `.toml` `.json` `.txt` `.wasm` `.node` `.html`
 
-Bun uses the file extension to determine which built-in _loader_ should be used to parse the file. Every loader has a name, such as `js`, `tsx`, or `json`. These names are used when building [plugins](https://bun.sh/docs/bundler/plugins) that extend Bun with custom loaders.
+Bun uses the file extension to determine which built-in _loader_ should be used to parse the file. Every loader has a name, such as `js`, `tsx`, or `json`. These names are used when building [plugins](https://bun.com/docs/bundler/plugins) that extend Bun with custom loaders.
 
 You can explicitly specify which loader to use using the 'loader' import attribute.
 
@@ -175,7 +175,7 @@ In the bundler, `.node` files are handled using the [`file`](#file) loader.
 
 **SQLite loader**. `with { "type": "sqlite" }` import attribute
 
-In the runtime and bundler, SQLite databases can be directly imported. This will load the database using [`bun:sqlite`](https://bun.sh/docs/api/sqlite).
+In the runtime and bundler, SQLite databases can be directly imported. This will load the database using [`bun:sqlite`](https://bun.com/docs/api/sqlite).
 
 ```ts
 import db from "./my.db" with { type: "sqlite" };
@@ -192,7 +192,7 @@ You can change this behavior with the `"embed"` attribute:
 import db from "./my.db" with { type: "sqlite", embed: "true" };
 ```
 
-When using a [standalone executable](https://bun.sh/docs/bundler/executables), the database is embedded into the single-file executable.
+When using a [standalone executable](https://bun.com/docs/bundler/executables), the database is embedded into the single-file executable.
 
 Otherwise, the database to embed is copied into the `outdir` with a hashed filename.
 
@@ -280,7 +280,7 @@ The `html` loader behaves differently depending on how it's used:
 
 **Bun Shell loader**. Default for `.sh` files
 
-This loader is used to parse [Bun Shell](https://bun.sh/docs/runtime/shell) scripts. It's only supported when starting Bun itself, so it's not available in the bundler or in the runtime.
+This loader is used to parse [Bun Shell](https://bun.com/docs/runtime/shell) scripts. It's only supported when starting Bun itself, so it's not available in the bundler or in the runtime.
 
 ```sh
 $ bun run ./script.sh
@@ -336,7 +336,7 @@ If a value is specified for `publicPath`, the import will use value as a prefix
 {% /table %}
 
 {% callout %}
-The location and file name of the copied file is determined by the value of [`naming.asset`](https://bun.sh/docs/bundler#naming).
+The location and file name of the copied file is determined by the value of [`naming.asset`](https://bun.com/docs/bundler#naming).
 {% /callout %}
 This loader is copied into the `outdir` as-is. The name of the copied file is determined using the value of `naming.asset`.
 

package/docs/bundler/macros.md

@@ -161,7 +161,7 @@ The result of `fetch` is `Promise<Response>`, so it can be directly returned.
 
 ```ts#macro.ts
 export function getObject() {
-  return fetch("https://bun.sh")
+  return fetch("https://bun.com")
 }
 ```
 

package/docs/bundler/plugins.md

@@ -291,7 +291,7 @@ One of the reasons why Bun's bundler is so fast is that it is written in native
 
 However, one limitation of plugins written in JavaScript is that JavaScript itself is single-threaded.
 
-Native plugins are written as [NAPI](https://bun.sh/docs/api/node-api) modules and can be run on multiple threads. This allows native plugins to run much faster than JavaScript plugins.
+Native plugins are written as [NAPI](https://bun.com/docs/api/node-api) modules and can be run on multiple threads. This allows native plugins to run much faster than JavaScript plugins.
 
 In addition, native plugins can skip unnecessary work such as the UTF-8 -> UTF-16 conversion needed to pass strings to JavaScript.
 

package/docs/bundler/vs-esbuild.md

@@ -2,7 +2,7 @@ Bun's bundler API is inspired heavily by [esbuild](https://esbuild.github.io/).
 
 There are a few behavioral differences to note.
 
-- **Bundling by default**. Unlike esbuild, Bun _always bundles by default_. This is why the `--bundle` flag isn't necessary in the Bun example. To transpile each file individually, use [`Bun.Transpiler`](https://bun.sh/docs/api/transpiler).
+- **Bundling by default**. Unlike esbuild, Bun _always bundles by default_. This is why the `--bundle` flag isn't necessary in the Bun example. To transpile each file individually, use [`Bun.Transpiler`](https://bun.com/docs/api/transpiler).
 - **It's just a bundler**. Unlike esbuild, Bun's bundler does not include a built-in development server or file watcher. It's just a bundler. The bundler is intended for use in conjunction with `Bun.serve` and other runtime APIs to achieve the same effect. As such, all options relating to HTTP/file watching are not applicable.
 
 ## Performance
@@ -65,7 +65,7 @@ In Bun's CLI, simple boolean flags like `--minify` do not accept an argument. Ot
 
 - `--loader:.ext=loader`
 - `--loader .ext:loader`
-- Bun supports a different set of built-in loaders than esbuild; see [Bundler > Loaders](https://bun.sh/docs/bundler/loaders) for a complete reference. The esbuild loaders `dataurl`, `binary`, `base64`, `copy`, and `empty` are not yet implemented.
+- Bun supports a different set of built-in loaders than esbuild; see [Bundler > Loaders](https://bun.com/docs/bundler/loaders) for a complete reference. The esbuild loaders `dataurl`, `binary`, `base64`, `copy`, and `empty` are not yet implemented.
 
   The syntax for `--loader` is slightly different.
 
@@ -474,7 +474,7 @@ In Bun's CLI, simple boolean flags like `--minify` do not accept an argument. Ot
 
 - `bundle`
 - n/a
-- Always `true`. Use [`Bun.Transpiler`](https://bun.sh/docs/api/transpiler) to transpile without bundling.
+- Always `true`. Use [`Bun.Transpiler`](https://bun.com/docs/api/transpiler) to transpile without bundling.
 
 ---
 
@@ -635,7 +635,7 @@ In Bun's CLI, simple boolean flags like `--minify` do not accept an argument. Ot
 
 - `loader`
 - `loader`
-- Bun supports a different set of built-in loaders than esbuild; see [Bundler > Loaders](https://bun.sh/docs/bundler/loaders) for a complete reference. The esbuild loaders `dataurl`, `binary`, `base64`, `copy`, and `empty` are not yet implemented.
+- Bun supports a different set of built-in loaders than esbuild; see [Bundler > Loaders](https://bun.com/docs/bundler/loaders) for a complete reference. The esbuild loaders `dataurl`, `binary`, `base64`, `copy`, and `empty` are not yet implemented.
 
 ---
 
@@ -891,7 +891,7 @@ const myPlugin: BunPlugin = {
 };
 ```
 
-The `builder` object provides some methods for hooking into parts of the bundling process. Bun implements `onResolve` and `onLoad`; it does not yet implement the esbuild hooks `onStart`, `onEnd`, and `onDispose`, and `resolve` utilities. `initialOptions` is partially implemented, being read-only and only having a subset of esbuild's options; use [`config`](https://bun.sh/docs/bundler/plugins) (same thing but with Bun's `BuildConfig` format) instead.
+The `builder` object provides some methods for hooking into parts of the bundling process. Bun implements `onResolve` and `onLoad`; it does not yet implement the esbuild hooks `onStart`, `onEnd`, and `onDispose`, and `resolve` utilities. `initialOptions` is partially implemented, being read-only and only having a subset of esbuild's options; use [`config`](https://bun.com/docs/bundler/plugins) (same thing but with Bun's `BuildConfig` format) instead.
 
 ```ts
 import type { BunPlugin } from "bun";

package/docs/cli/bun-create.md

@@ -4,7 +4,7 @@
 
 Template a new Bun project with `bun create`. This is a flexible command that can be used to create a new project from a React component, a `create-<template>` npm package, a GitHub repo, or a local template.
 
-If you're looking to create a brand new empty project, use [`bun init`](https://bun.sh/docs/cli/init).
+If you're looking to create a brand new empty project, use [`bun init`](https://bun.com/docs/cli/init).
 
 ## From a React component
 
@@ -30,11 +30,11 @@ $ bun create ./MyComponent.jsx # .tsx also supported
 
 When you run `bun create <component>`, Bun:
 
-1. Uses [Bun's JavaScript bundler](https://bun.sh/docs/bundler) to analyze your module graph.
+1. Uses [Bun's JavaScript bundler](https://bun.com/docs/bundler) to analyze your module graph.
 2. Collects all the dependencies needed to run the component.
 3. Scans the exports of the entry point for a React component.
 4. Generates a `package.json` file with the dependencies and scripts needed to run the component.
-5. Installs any missing dependencies using [`bun install --only-missing`](https://bun.sh/docs/cli/install).
+5. Installs any missing dependencies using [`bun install --only-missing`](https://bun.com/docs/cli/install).
 6. Generates the following files:
    - `${component}.html`
    - `${component}.client.tsx` (entry point for the frontend)

package/docs/cli/bun-install.md

@@ -184,7 +184,7 @@ Peer dependencies are handled similarly to yarn. `bun install` will automaticall
 
 ## Lockfile
 
-`bun.lock` is Bun’s lockfile format. See [our blogpost about the text lockfile](https://bun.sh/blog/bun-lock-text-lockfile).
+`bun.lock` is Bun’s lockfile format. See [our blogpost about the text lockfile](https://bun.com/blog/bun-lock-text-lockfile).
 
 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`.