bun-types 1.3.2-canary.20251105T140650 → 1.3.2

package/docs/{cli/publish.md → pm/cli/publish.mdx}

@@ -1,13 +1,19 @@
-Use `bun publish` to publish a package to the npm registry.
+---
+title: "bun publish"
+description: Use `bun publish` to publish a package to the npm registry
+---
+
+import Publish from "/snippets/cli/publish.mdx";
 
 `bun publish` will automatically pack your package into a tarball, strip catalog and workspace protocols from the `package.json` (resolving versions if necessary), and publish to the registry specified in your configuration files. Both `bunfig.toml` and `.npmrc` files are supported.
 
-```sh
+```sh terminal icon="terminal"
 ## Publishing the package from the current working directory
-$ bun publish
+bun publish
+```
 
-## Output
-bun publish v1.3.2-canary.20251105T140650 (ca7428e9)
+```txt
+bun publish v1.3.1 (ca7428e9)
 
 packed 203B package.json
 packed 224B README.md
@@ -28,27 +34,28 @@ Registry: http://localhost:4873/
 
 Alternatively, you can pack and publish your package separately by using `bun pm pack` followed by `bun publish` with the path to the output tarball.
 
-```sh
-$ bun pm pack
+```sh terminal icon="terminal"
+bun pm pack
 ...
-$ bun publish ./package.tgz
+bun publish ./package.tgz
 ```
 
-{% callout %}
-**Note** - `bun publish` will not run lifecycle scripts (`prepublishOnly/prepack/prepare/postpack/publish/postpublish`) if a tarball path is provided. Scripts will only be run if the package is packed by `bun publish`.
-{% /callout %}
+<Note>
+  `bun publish` will not run lifecycle scripts (`prepublishOnly/prepack/prepare/postpack/publish/postpublish`) if a
+  tarball path is provided. Scripts will only be run if the package is packed by `bun publish`.
+</Note>
 
 ### `--access`
 
 The `--access` flag can be used to set the access level of the package being published. The access level can be one of `public` or `restricted`. Unscoped packages are always public, and attempting to publish an unscoped package with `--access restricted` will result in an error.
 
-```sh
-$ bun publish --access public
+```sh terminal icon="terminal"
+bun publish --access public
 ```
 
 `--access` can also be set in the `publishConfig` field of your `package.json`.
 
-```json
+```json package.json icon="file-json"
 {
   "publishConfig": {
     "access": "restricted"
@@ -60,13 +67,13 @@ $ bun publish --access public
 
 Set the tag of the package version being published. By default, the tag is `latest`. The initial version of a package is always given the `latest` tag in addition to the specified tag.
 
-```sh
-$ bun publish --tag alpha
+```sh terminal icon="terminal"
+bun publish --tag alpha
 ```
 
 `--tag` can also be set in the `publishConfig` field of your `package.json`.
 
-```json
+```json package.json icon="file-json"
 {
   "publishConfig": {
     "tag": "next"
@@ -78,29 +85,20 @@ $ bun publish --tag alpha
 
 The `--dry-run` flag can be used to simulate the publish process without actually publishing the package. This is useful for verifying the contents of the published package without actually publishing the package.
 
-```sh
-$ bun publish --dry-run
-```
-
-### `--tolerate-republish`
-
-Exit with code 0 instead of 1 if the package version already exists. Useful in CI/CD where jobs may be re-run.
-
-```sh
-$ bun publish --tolerate-republish
+```sh terminal icon="terminal"
+bun publish --dry-run
 ```
 
 ### `--gzip-level`
 
 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`).
-{% bunCLIUsage command="publish" /%}
 
 ### `--auth-type`
 
 If you have 2FA enabled for your npm account, `bun publish` will prompt you for a one-time password. This can be done through a browser or the CLI. The `--auth-type` flag can be used to tell the npm registry which method you prefer. The possible values are `web` and `legacy`, with `web` being the default.
 
-```sh
-$ bun publish --auth-type legacy
+```sh terminal icon="terminal"
+bun publish --auth-type legacy
 ...
 This operation requires a one-time password.
 Enter OTP: 123456
@@ -111,10 +109,15 @@ Enter OTP: 123456
 
 Provide a one-time password directly to the CLI. If the password is valid, this will skip the extra prompt for a one-time password before publishing. Example usage:
 
-```sh
-$ bun publish --otp 123456
+```sh terminal icon="terminal"
+bun publish --otp 123456
 ```
 
-{% callout %}
-**Note** - `bun publish` respects the `NPM_CONFIG_TOKEN` environment variable which can be used when publishing in github actions or automated workflows.
-{% /callout %}
+<Note>
+  `bun publish` respects the `NPM_CONFIG_TOKEN` environment variable which can be used when publishing in github actions
+  or automated workflows.
+</Note>
+
+---
+
+<Publish />

package/docs/pm/cli/remove.mdx

@@ -0,0 +1,16 @@
+---
+title: "bun remove"
+description: "Remove dependencies from your project"
+---
+
+import Remove from "/snippets/cli/remove.mdx";
+
+## Basic Usage
+
+```bash terminal icon="terminal"
+bun remove ts-node
+```
+
+---
+
+<Remove />

package/docs/{cli/update.md → pm/cli/update.mdx}

@@ -1,22 +1,31 @@
+---
+title: "bun update"
+description: "Update dependencies to latest versions"
+---
+
+import Update from "/snippets/cli/update.mdx";
+
+<Note>To upgrade your Bun CLI version, see [`bun upgrade`](/installation#upgrading).</Note>
+
 To update all dependencies to the latest version:
 
-```sh
-$ bun update
+```sh terminal icon="terminal"
+bun update
 ```
 
 To update a specific dependency to the latest version:
 
-```sh
-$ bun update [package]
+```sh terminal icon="terminal"
+bun update [package]
 ```
 
 ## `--interactive`
 
 For a more controlled update experience, use the `--interactive` flag to select which packages to update:
 
-```sh
-$ bun update --interactive
-$ bun update -i
+```sh terminal icon="terminal"
+bun update --interactive
+bun update -i
 ```
 
 This launches an interactive terminal interface that shows all outdated packages with their current and target versions. You can then select which packages to update.
@@ -25,7 +34,7 @@ This launches an interactive terminal interface that shows all outdated packages
 
 The interface displays packages grouped by dependency type:
 
-```
+```txt
 ? Select packages to update - Space to toggle, Enter to confirm, a to select all, n to select none, i to invert, l to toggle latest
 
   dependencies                Current  Target   Latest
@@ -94,9 +103,9 @@ Within each section, individual packages may have additional suffixes (` dev`, `
 
 Use the `--recursive` flag with `--interactive` to update dependencies across all workspaces in a monorepo:
 
-```sh
-$ bun update --interactive --recursive
-$ bun update -i -r
+```sh terminal icon="terminal"
+bun update --interactive --recursive
+bun update -i -r
 ```
 
 This displays an additional "Workspace" column showing which workspace each dependency belongs to.
@@ -107,15 +116,15 @@ By default, `bun update` will update to the latest version of a dependency that
 
 To update to the latest version, regardless of if it's compatible with the current version range, use the `--latest` flag:
 
-```sh
-$ bun update --latest
+```sh terminal icon="terminal"
+bun update --latest
 ```
 
 In interactive mode, you can toggle individual packages between their target version (respecting semver) and latest version using the **l** key.
 
 For example, with the following `package.json`:
 
-```json
+```json package.json icon="file-json"
 {
   "dependencies": {
     "react": "^17.0.2"
@@ -126,4 +135,6 @@ For example, with the following `package.json`:
 - `bun update` would update to a version that matches `17.x`.
 - `bun update --latest` would update to a version that matches `18.x` or later.
 
-{% bunCLIUsage command="update" /%}
+---
+
+<Update />

package/docs/{cli/why.md → pm/cli/why.mdx}

@@ -1,9 +1,14 @@
+---
+title: "bun why"
+description: "Explain why a package is installed"
+---
+
 The `bun why` command explains why a package is installed in your project by showing the dependency chain that led to its installation.
 
 ## Usage
 
-```bash
-$ bun why <package>
+```bash terminal icon="terminal"
+bun why <package>
 ```
 
 ## Arguments
@@ -19,16 +24,22 @@ $ bun why <package>
 
 Check why a specific package is installed:
 
-```bash
-$ bun why react
+```bash terminal icon="terminal"
+bun why react
+```
+
+```txt
 react@18.2.0
   └─ my-app@1.0.0 (requires ^18.0.0)
 ```
 
 Check why all packages with a specific pattern are installed:
 
-```bash
-$ bun why "@types/*"
+```bash terminal icon="terminal"
+bun why "@types/*"
+```
+
+```txt
 @types/react@18.2.15
   └─ dev my-app@1.0.0 (requires ^18.0.0)
 
@@ -38,16 +49,22 @@ $ bun why "@types/*"
 
 Show only top-level dependencies:
 
-```bash
-$ bun why express --top
+```bash terminal icon="terminal"
+bun why express --top
+```
+
+```txt
 express@4.18.2
   └─ my-app@1.0.0 (requires ^4.18.2)
 ```
 
 Limit the dependency tree depth:
 
-```bash
-$ bun why express --depth 2
+```bash terminal icon="terminal"
+bun why express --depth 2
+```
+
+```txt
 express@4.18.2
   └─ express-pollyfill@1.20.1 (requires ^4.18.2)
      └─ body-parser@1.20.1 (requires ^1.20.1)

package/docs/{cli/filter.md → pm/filter.mdx}

@@ -1,7 +1,14 @@
+---
+title: "bun --filter"
+description: "Select packages by pattern in a monorepo using the --filter flag"
+---
+
 The `--filter` (or `-F`) flag is used for selecting packages by pattern in a monorepo. Patterns can be used to match package names or package paths, with full glob syntax support.
 
 Currently `--filter` is supported by `bun install` and `bun outdated`, and can also be used to run scripts for multiple packages at once.
 
+---
+
 ## Matching
 
 ### Package Name `--filter <pattern>`
@@ -12,6 +19,8 @@ Name patterns select packages based on the package name, as specified in `packag
 
 Path patterns are specified by starting the pattern with `./`, and will select all packages in directories that match the pattern. For example, to match all packages in subdirectories of `packages`, you can use `--filter './packages/**'`. To match a package located in `packages/foo`, use `--filter ./packages/foo`.
 
+---
+
 ## `bun install` and `bun outdated`
 
 Both `bun install` and `bun outdated` support the `--filter` flag.
@@ -20,40 +29,42 @@ Both `bun install` and `bun outdated` support the `--filter` flag.
 
 Given a monorepo with workspaces `pkg-a`, `pkg-b`, and `pkg-c` under `./packages`:
 
-```bash
+```bash terminal icon="terminal"
 # Install dependencies for all workspaces except `pkg-c`
-$ bun install --filter '!pkg-c'
+bun install --filter '!pkg-c'
 
 # Install dependencies for packages in `./packages` (`pkg-a`, `pkg-b`, `pkg-c`)
-$ bun install --filter './packages/*'
+bun install --filter './packages/*'
 
 # Save as above, but exclude the root package.json
-$ bun install --filter '!./' --filter './packages/*'
+bun install --filter '!./' --filter './packages/*'
 ```
 
 Similarly, `bun outdated` will display outdated dependencies for all packages in the monorepo, and `--filter` can be used to restrict the command to a subset of the packages:
 
-```bash
+```bash terminal icon="terminal"
 # Display outdated dependencies for workspaces starting with `pkg-`
-$ bun outdated --filter 'pkg-*'
+bun outdated --filter 'pkg-*'
 
 # Display outdated dependencies for only the root package.json
-$ bun outdated --filter './'
+bun outdated --filter './'
 ```
 
-For more information on both these commands, see [`bun install`](https://bun.com/docs/cli/install) and [`bun outdated`](https://bun.com/docs/cli/outdated).
+For more information on both these commands, see [`bun install`](/pm/cli/install) and [`bun outdated`](/pm/cli/outdated).
+
+---
 
 ## Running scripts with `--filter`
 
 Use the `--filter` flag to execute scripts in multiple packages at once:
 
-```bash
+```bash terminal icon="terminal"
 bun --filter <pattern> <script>
 ```
 
 Say you have a monorepo with two packages: `packages/api` and `packages/frontend`, both with a `dev` script that will start a local development server. Normally, you would have to open two separate terminal tabs, cd into each package directory, and run `bun dev`:
 
-```bash
+```bash terminal icon="terminal"
 cd packages/api
 bun dev
 
@@ -64,19 +75,20 @@ bun dev
 
 Using `--filter`, you can run the `dev` script in both packages at once:
 
-```bash
+```bash terminal icon="terminal"
 bun --filter '*' dev
 ```
 
 Both commands will be run in parallel, and you will see a nice terminal UI showing their respective outputs:
-![Terminal Output](https://github.com/oven-sh/bun/assets/48869301/2a103e42-9921-4c33-948f-a1ad6e6bac71)
+
+<Frame>![Terminal Output](https://github.com/oven-sh/bun/assets/48869301/2a103e42-9921-4c33-948f-a1ad6e6bac71)</Frame>
 
 ### Running scripts in workspaces
 
-Filters respect your [workspace configuration](https://bun.com/docs/install/workspaces): If you have a `package.json` file that specifies which packages are part of the workspace,
+Filters respect your [workspace configuration](/pm/workspaces): If you have a `package.json` file that specifies which packages are part of the workspace,
 `--filter` will be restricted to only these packages. Also, in a workspace you can use `--filter` to run scripts in packages that are located anywhere in the workspace:
 
-```bash
+```bash terminal icon="terminal"
 # Packages
 # src/foo
 # src/bar

package/docs/{install/cache.md → pm/global-cache.mdx}

@@ -1,8 +1,13 @@
+---
+title: "Global cache"
+description: "How Bun stores and manages packages in its global cache"
+---
+
 All packages downloaded from the registry are stored in a global cache at `~/.bun/install/cache`, or the path defined by the environment variable `BUN_INSTALL_CACHE_DIR`. They are stored in subdirectories named like `${name}@${version}`, so multiple versions of a package can be cached.
 
-{% details summary="Configuring cache behavior (bunfig.toml)" %}
+<Accordion title="Configuring cache behavior">
 
-```toml
+```toml bunfig.toml icon="settings"
 [install.cache]
 # the directory to use for the cache
 dir = "~/.bun/install/cache"
@@ -15,31 +20,38 @@ disable = false
 disableManifest = false
 ```
 
-{% /details %}
+</Accordion>
+
+---
 
 ## Minimizing re-downloads
 
 Bun strives to avoid re-downloading packages multiple times. When installing a package, if the cache already contains a version in the range specified by `package.json`, Bun will use the cached package instead of downloading it again.
 
-{% details summary="Installation details" %}
+<Accordion title="Installation details">
 If the semver version has pre-release suffix (`1.0.0-beta.0`) or a build suffix (`1.0.0+20220101`), it is replaced with a hash of that value instead, to reduce the chances of errors associated with long file paths.
 
 When the `node_modules` folder exists, before installing, Bun checks that `node_modules` contains all expected packages with appropriate versions. If so `bun install` completes. Bun uses a custom JSON parser which stops parsing as soon as it finds `"name"` and `"version"`.
 
 If a package is missing or has a version incompatible with the `package.json`, Bun checks for a compatible module in the cache. If found, it is installed into `node_modules`. Otherwise, the package will be downloaded from the registry then installed.
-{% /details %}
+
+</Accordion>
+
+---
 
 ## Fast copying
 
 Once a package is downloaded into the cache, Bun still needs to copy those files into `node_modules`. Bun uses the fastest syscalls available to perform this task. On Linux, it uses hardlinks; on macOS, it uses `clonefile`.
 
+---
+
 ## Saving disk space
 
 Since Bun uses hardlinks to "copy" a module into a project's `node_modules` directory on Linux and Windows, the contents of the package only exist in a single location on disk, greatly reducing the amount of disk space dedicated to `node_modules`.
 
 This benefit also applies to macOS, but there are exceptions. It uses `clonefile` which is copy-on-write, meaning it will not occupy disk space, but it will count towards drive's limit. This behavior is useful if something attempts to patch `node_modules/*`, so it's impossible to affect other installations.
 
-{% details summary="Installation strategies" %}
+<Accordion title="Installation strategies">
 This behavior is configurable with the `--backend` flag, which is respected by all of Bun's package management commands.
 
 - **`hardlink`**: Default on Linux and Windows.
@@ -48,12 +60,13 @@ This behavior is configurable with the `--backend` flag, which is respected by a
 - **`copyfile`**: The fallback used when any of the above fail. It is the slowest option. On macOS, it uses `fcopyfile()`; on Linux it uses `copy_file_range()`.
 - **`symlink`**: Currently used only `file:` (and eventually `link:`) dependencies. To prevent infinite loops, it skips symlinking the `node_modules` folder.
 
-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).
+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`. See [Node.js documentation on `--preserve-symlinks`](https://nodejs.org/api/cli.html#--preserve-symlinks).
 
-```bash
-$ bun install --backend symlink
-$ node --preserve-symlinks ./foo.js
-$ bun --preserve-symlinks ./foo.js
+```bash terminal icon="terminal"
+bun install --backend symlink
+node --preserve-symlinks ./foo.js
 ```
 
-{% /details %}
+Bun's runtime does not currently expose an equivalent of `--preserve-symlinks`.
+
+</Accordion>

package/docs/{install/isolated.md → pm/isolated-installs.mdx}

@@ -1,5 +1,12 @@
+---
+title: "Isolated installs"
+description: "Strict dependency isolation similar to pnpm's approach"
+---
+
 Bun provides an alternative package installation strategy called **isolated installs** that creates strict dependency isolation similar to pnpm's approach. This mode prevents phantom dependencies and ensures reproducible, deterministic builds.
 
+This is the default installation strategy for monorepo projects.
+
 ## What are isolated installs?
 
 Isolated installs create a non-hoisted dependency structure where packages can only access their explicitly declared dependencies. This differs from the traditional "hoisted" installation strategy used by npm and Yarn, where dependencies are flattened into a shared `node_modules` directory.
@@ -17,29 +24,29 @@ Isolated installs create a non-hoisted dependency structure where packages can o
 
 Use the `--linker` flag to specify the installation strategy:
 
-```bash
+```bash terminal icon="terminal"
 # Use isolated installs
-$ bun install --linker isolated
+bun install --linker isolated
 
 # Use traditional hoisted installs
-$ bun install --linker hoisted
+bun install --linker hoisted
 ```
 
 ### Configuration file
 
-Set the default linker strategy in your `bunfig.toml`:
+Set the default linker strategy in your `bunfig.toml` or globally in `$HOME/.bunfig.toml`:
 
-```toml
+```toml bunfig.toml icon="settings"
 [install]
 linker = "isolated"
 ```
 
 ### Default behavior
 
-- **Workspaces**: Bun uses **isolated** installs by default to prevent hoisting-related bugs
-- **Single projects**: Bun uses **hoisted** installs by default
+- For monorepo projects, Bun uses the **isolated** installation strategy by default.
+- For single-project projects, Bun uses the **hoisted** installation strategy by default.
 
-To override the default, use `--linker hoisted` or `--linker isolated`, or set it in your configuration file.
+You can override the default behavior by explicitly specifying the `--linker` flag or setting it in your configuration file.
 
 ## How isolated installs work
 
@@ -47,7 +54,7 @@ To override the default, use `--linker hoisted` or `--linker isolated`, or set i
 
 Instead of hoisting dependencies, isolated installs create a two-tier structure:
 
-```
+```bash tree layout of node_modules icon="list-tree"
 node_modules/
 ├── .bun/                          # Central package store
 │   ├── package@1.0.0/             # Versioned package installations
@@ -93,7 +100,7 @@ In monorepos, workspace dependencies are handled specially:
 
 Isolated installs handle peer dependencies through sophisticated resolution:
 
-```bash
+```bash tree layout of node_modules icon="list-tree"
 # Package with peer dependencies creates specialized paths
 node_modules/.bun/package@1.0.0_react@18.2.0/
 ```
@@ -112,8 +119,8 @@ Bun uses different file operation strategies for performance:
 
 Enable verbose logging to understand the installation process:
 
-```bash
-$ bun install --linker isolated --verbose
+```bash terminal icon="terminal"
+bun install --linker isolated --verbose
 ```
 
 This shows:
@@ -137,8 +144,8 @@ If you encounter issues, you can:
 
 1. **Switch to hoisted mode** for specific projects:
 
-   ```bash
-   $ bun install --linker hoisted
+   ```bash terminal icon="terminal"
+   bun install --linker hoisted
    ```
 
 2. **Report compatibility issues** to help improve isolated install support
@@ -153,37 +160,38 @@ If you encounter issues, you can:
 
 ### From npm/Yarn
 
-```bash
+```bash terminal icon="terminal"
 # Remove existing node_modules and lockfiles
-$ rm -rf node_modules package-lock.json yarn.lock
+rm -rf node_modules package-lock.json yarn.lock
 
 # Install with isolated linker
-$ bun install --linker isolated
+bun install --linker isolated
 ```
 
 ### From pnpm
 
 Isolated installs are conceptually similar to pnpm, so migration should be straightforward:
 
-```bash
+```bash terminal icon="terminal"
 # Remove pnpm files
 $ rm -rf node_modules pnpm-lock.yaml
 
 # Install with Bun's isolated linker
-$ bun install --linker isolated
+bun install --linker isolated
 ```
 
 The main difference is that Bun uses symlinks in `node_modules` while pnpm uses a global store with symlinks.
 
 ## When to use isolated installs
 
-**Isolated installs are the default for workspaces.** You may want to explicitly enable them for single projects when:
+**Use isolated installs when:**
 
+- Working in monorepos with multiple packages
 - Strict dependency management is required
 - Preventing phantom dependencies is important
 - Building libraries that need deterministic dependencies
 
-**Switch to hoisted installs (including for workspaces) when:**
+**Use hoisted installs when:**
 
 - Working with legacy code that assumes flat `node_modules`
 - Compatibility with existing build tools is required
@@ -192,6 +200,6 @@ The main difference is that Bun uses symlinks in `node_modules` while pnpm uses
 
 ## Related documentation
 
-- [Package manager > Workspaces](https://bun.com/docs/install/workspaces) — Monorepo workspace management
-- [Package manager > Lockfile](https://bun.com/docs/install/lockfile) — Understanding Bun's lockfile format
-- [CLI > install](https://bun.com/docs/cli/install) — Complete `bun install` command reference
+- [Package manager > Workspaces](/pm/workspaces) — Monorepo workspace management
+- [Package manager > Lockfile](/pm/lockfile) — Understanding Bun's lockfile format
+- [CLI > install](/pm/cli/install) — Complete `bun install` command reference