bun-types 1.3.2-canary.20251105T140650 → 1.3.2-canary.20251106T140813

package/docs/install/overrides.md

@@ -1,73 +0,0 @@
-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.
-
-```json-diff#package.json
-  {
-    "name": "my-app",
-    "dependencies": {
-      "foo": "^2.0.0"
-    },
-+   "overrides": {
-+     "bar": "~4.4.0"
-+   }
-  }
-```
-
-By default, Bun will install the latest version of all dependencies and metadependencies, according to the ranges specified in each package's `package.json`. Let's say you have a project with one dependency, `foo`, which in turn has a dependency on `bar`. This means `bar` is a _metadependency_ of our project.
-
-```json#package.json
-{
-  "name": "my-app",
-  "dependencies": {
-    "foo": "^2.0.0"
-  }
-}
-```
-
-When you run `bun install`, Bun will install the latest versions of each package.
-
-```
-# tree layout of node_modules
-node_modules
-├── foo@1.2.3
-└── bar@4.5.6
-```
-
-But what if a security vulnerability was introduced in `bar@4.5.6`? We may want a way to pin `bar` to an older version that doesn't have the vulnerability. This is where `"overrides"`/`"resolutions"` come in.
-
-## `"overrides"`
-
-Add `bar` to the `"overrides"` field in `package.json`. Bun will defer to the specified version range when determining which version of `bar` to install, whether it's a dependency or a metadependency.
-
-{% callout %}
-**Note** — Bun currently only supports top-level `"overrides"`. [Nested overrides](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides) are not supported.
-{% /callout %}
-
-```json-diff#package.json
-  {
-    "name": "my-app",
-    "dependencies": {
-      "foo": "^2.0.0"
-    },
-+   "overrides": {
-+     "bar": "~4.4.0"
-+   }
-  }
-```
-
-## `"resolutions"`
-
-The syntax is similar for `"resolutions"`, which is Yarn's alternative to `"overrides"`. Bun supports this feature to make migration from Yarn easier.
-
-As with `"overrides"`, _nested resolutions_ are not currently supported.
-
-```json-diff#package.json
-  {
-    "name": "my-app",
-    "dependencies": {
-      "foo": "^2.0.0"
-    },
-+   "resolutions": {
-+     "bar": "~4.4.0"
-+   }
-  }
-```

package/docs/install/patch.md

@@ -1,59 +0,0 @@
-`bun patch` lets you persistently patch node_modules in a maintainable, git-friendly way.
-
-Sometimes, you need to make a small change to a package in `node_modules/` to fix a bug or add a feature. `bun patch` makes it easy to do this without vendoring the entire package and reuse the patch across multiple installs, multiple projects, and multiple machines.
-
-Features:
-
-- Generates `.patch` files applied to dependencies in `node_modules` on install
-- `.patch` files can be committed to your repository, reused across multiple installs, projects, and machines
-- `"patchedDependencies"` in `package.json` keeps track of patched packages
-- `bun patch` lets you patch packages in `node_modules/` while preserving the integrity of Bun's [Global Cache](https://bun.com/docs/install/cache)
-- Test your changes locally before committing them with `bun patch --commit <pkg>`
-- To preserve disk space and keep `bun install` fast, patched packages are committed to the Global Cache and shared across projects where possible
-
-#### Step 1. Prepare the package for patching
-
-To get started, use `bun patch <pkg>` to prepare the package for patching:
-
-```bash
-# you can supply the package name
-$ bun patch react
-
-# ...and a precise version in case multiple versions are installed
-$ bun patch react@17.0.2
-
-# or the path to the package
-$ bun patch node_modules/react
-```
-
-{% callout %}
-**Note** — Don't forget to call `bun patch <pkg>`! This ensures the package folder in `node_modules/` contains a fresh copy of the package with no symlinks/hardlinks to Bun's cache.
-
-If you forget to do this, you might end up editing the package globally in the cache!
-{% /callout %}
-
-#### Step 2. Test your changes locally
-
-`bun patch <pkg>` makes it safe to edit the `<pkg>` in `node_modules/` directly, while preserving the integrity of Bun's [Global Cache](https://bun.com/docs/install/cache). This works by re-creating an unlinked clone of the package in `node_modules/` and diffing it against the original package in the Global Cache.
-
-#### Step 3. Commit your changes
-
-Once you're happy with your changes, run `bun patch --commit <path or pkg>`.
-
-Bun will generate a patch file in `patches/`, update your `package.json` and lockfile, and Bun will start using the patched package:
-
-```bash
-# you can supply the path to the patched package
-$ bun patch --commit node_modules/react
-
-# ... or the package name and optionally the version
-$ bun patch --commit react@17.0.2
-
-# choose the directory to store the patch files
-$ bun patch --commit react --patches-dir=mypatches
-
-# `patch-commit` is available for compatibility with pnpm
-$ bun patch-commit react
-```
-
-{% bunCLIUsage command="patch" /%}

package/docs/install/registries.md

@@ -1,30 +0,0 @@
-The default registry is `registry.npmjs.org`. This can be globally configured in `bunfig.toml`:
-
-```toml
-[install]
-# set default registry as a string
-registry = "https://registry.npmjs.org"
-# set a token
-registry = { url = "https://registry.npmjs.org", token = "123456" }
-# set a username/password
-registry = "https://username:password@registry.npmjs.org"
-```
-
-To configure a private registry scoped to a particular organization:
-
-```toml
-[install.scopes]
-# registry as string
-"@myorg1" = "https://username:password@registry.myorg.com/"
-
-# registry with username/password
-# you can reference environment variables
-"@myorg2" = { username = "myusername", password = "$NPM_PASS", url = "https://registry.myorg.com/" }
-
-# registry with token
-"@myorg3" = { token = "$npm_token", url = "https://registry.myorg.com/" }
-```
-
-### `.npmrc`
-
-Bun also reads `.npmrc` files, [learn more](https://bun.com/docs/install/npmrc).

package/docs/install/security-scanner-api.md

@@ -1,81 +0,0 @@
-Bun's package manager can scan packages for security vulnerabilities before installation, helping protect your applications from supply chain attacks and known vulnerabilities.
-
-## Quick Start
-
-Configure a security scanner in your `bunfig.toml`:
-
-```toml
-[install.security]
-scanner = "@acme/bun-security-scanner"
-```
-
-When configured, Bun will:
-
-- Scan all packages before installation
-- Display security warnings and advisories
-- Cancel installation if critical vulnerabilities are found
-- Automatically disable auto-install for security
-
-## How It Works
-
-Security scanners analyze packages during `bun install`, `bun add`, and other package operations. They can detect:
-
-- Known security vulnerabilities (CVEs)
-- Malicious packages
-- License compliance issues
-- ...and more!
-
-### Security Levels
-
-Scanners report issues at two severity levels:
-
-- **`fatal`** - Installation stops immediately, exits with non-zero code
-- **`warn`** - In interactive terminals, prompts to continue; in CI, exits immediately
-
-## Using Pre-built Scanners
-
-Many security companies publish Bun security scanners as npm packages that you can install and use immediately.
-
-### Installing a Scanner
-
-Install a security scanner from npm:
-
-```bash
-$ bun add -d @acme/bun-security-scanner
-```
-
-> **Note:** Consult your security scanner's documentation for their specific package name and installation instructions. Most scanners will be installed with `bun add`.
-
-### Configuring the Scanner
-
-After installation, configure it in your `bunfig.toml`:
-
-```toml
-[install.security]
-scanner = "@acme/bun-security-scanner"
-```
-
-### Enterprise Configuration
-
-Some enterprise scanners might support authentication and/or configuration through environment variables:
-
-```bash
-# This might go in ~/.bashrc, for example
-export SECURITY_API_KEY="your-api-key"
-
-# The scanner will now use these credentials automatically
-bun install
-```
-
-Consult your security scanner's documentation to learn which environment variables to set and if any additional configuration is required.
-
-### Authoring your own scanner
-
-For a complete example with tests and CI setup, see the official template:
-[github.com/oven-sh/security-scanner-template](https://github.com/oven-sh/security-scanner-template)
-
-## Related
-
-- [Configuration (bunfig.toml)](/docs/runtime/bunfig#install-security-scanner)
-- [Package Manager](/docs/install)
-- [Security Scanner Template](https://github.com/oven-sh/security-scanner-template)

package/docs/install/workspaces.md

@@ -1,114 +0,0 @@
-Bun supports [`workspaces`](https://docs.npmjs.com/cli/v9/using-npm/workspaces?v=true#description) in `package.json`. Workspaces make it easy to develop complex software as a _monorepo_ consisting of several independent packages.
-
-It's common for a monorepo to have the following structure:
-
-```
-tree
-<root>
-├── README.md
-├── bun.lock
-├── package.json
-├── tsconfig.json
-└── packages
-    ├── pkg-a
-    │   ├── index.ts
-    │   ├── package.json
-    │   └── tsconfig.json
-    ├── pkg-b
-    │   ├── index.ts
-    │   ├── package.json
-    │   └── tsconfig.json
-    └── pkg-c
-        ├── index.ts
-        ├── package.json
-        └── tsconfig.json
-```
-
-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`.
-
-```json
-{
-  "name": "my-project",
-  "version": "1.0.0",
-  "workspaces": ["packages/*"],
-  "devDependencies": {
-    "example-package-in-monorepo": "workspace:*"
-  }
-}
-```
-
-{% callout %}
-**Glob support** — Bun supports full glob syntax in `"workspaces"`, including negative patterns (e.g. `!**/excluded/**`). See [here](https://bun.com/docs/api/glob#supported-glob-patterns) for a comprehensive list of supported syntax.
-{% /callout %}
-
-```json
-{
-  "name": "my-project",
-  "version": "1.0.0",
-  "workspaces": [
-    "packages/**",
-    "!packages/**/test/**",
-    "!packages/**/template/**"
-  ]
-}
-```
-
-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`.
-
-```json
-{
-  "name": "pkg-a",
-  "version": "1.0.0",
-  "dependencies": {
-    "pkg-b": "workspace:*"
-  }
-}
-```
-
-`bun install` will install dependencies for all workspaces in the monorepo, de-duplicating packages if possible. If you only want to install dependencies for specific workspaces, you can use the `--filter` flag.
-
-```bash
-# Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`
-$ bun install --filter "pkg-*" --filter "!pkg-c"
-
-# Paths can also be used. This is equivalent to the command above.
-$ bun install --filter "./packages/pkg-*" --filter "!pkg-c" # or --filter "!./packages/pkg-c"
-```
-
-When publishing, `workspace:` versions are replaced by the package's `package.json` version,
-
-```
-"workspace:*" -> "1.0.1"
-"workspace:^" -> "^1.0.1"
-"workspace:~" -> "~1.0.1"
-```
-
-Setting a specific version takes precedence over the package's `package.json` version,
-
-```
-"workspace:1.0.2" -> "1.0.2" // Even if current version is 1.0.1
-```
-
-Workspaces have a couple major benefits.
-
-- **Code can be split into logical parts.** If one package relies on another, you can simply add it as a dependency in `package.json`. If package `b` depends on `a`, `bun install` will install your local `packages/a` directory into `node_modules` instead of downloading it from the npm registry.
-- **Dependencies can be de-duplicated.** If `a` and `b` share a common dependency, it will be _hoisted_ to the root `node_modules` directory. This reduces redundant disk usage and minimizes "dependency hell" issues associated with having multiple versions of a package installed simultaneously.
-- **Run scripts in multiple packages.** You can use the [`--filter` flag](https://bun.com/docs/cli/filter) to easily run `package.json` scripts in multiple packages in your workspace, or `--workspaces` to run scripts across all workspaces.
-
-## Share versions with Catalogs
-
-When many packages need the same dependency versions, catalogs let you define
-those versions once in the root `package.json` and reference them from your
-workspaces using the `catalog:` protocol. Updating the catalog automatically
-updates every package that references it. See
-[Catalogs](https://bun.com/docs/install/catalogs) for details.
-
-{% callout %}
-⚡️ **Speed** — Installs are fast, even for big monorepos. Bun installs the [Remix](https://github.com/remix-run/remix) monorepo in about `500ms` on Linux.
-
-- 28x faster than `npm install`
-- 12x faster than `yarn install` (v1)
-- 8x faster than `pnpm install`
-
-{% image src="https://user-images.githubusercontent.com/709451/212829600-77df9544-7c9f-4d8d-a984-b2cd0fd2aa52.png" /%}
-{% /callout %}

package/docs/installation.md

@@ -1,327 +0,0 @@
-Bun ships as a single executable with no dependencies that can be installed a few different ways.
-
-## Installing
-
-### macOS and Linux
-
-{% callout %}
-**Linux users** — The `unzip` package is required to install Bun. Use `sudo apt install unzip` to install `unzip` package.
-Kernel version 5.6 or higher is strongly recommended, but the minimum is 5.1. Use `uname -r` to check Kernel version.
-{% /callout %}
-
-{% codetabs %}
-
-```bash#macOS/Linux_(curl)
-$ curl -fsSL https://bun.com/install | bash # for macOS, Linux, and WSL
-# to install a specific version
-$ curl -fsSL https://bun.com/install | bash -s "bun-v1.3.2-canary.20251105T140650"
-```
-
-```bash#npm
-$ npm install -g bun # the last `npm` command you'll ever need
-```
-
-```bash#Homebrew
-$ brew install oven-sh/bun/bun # for macOS and Linux
-```
-
-```bash#Docker
-$ docker pull oven/bun
-$ docker run --rm --init --ulimit memlock=-1:-1 oven/bun
-```
-
-{% /codetabs %}
-
-### Windows
-
-To install, paste this into a terminal:
-
-{% codetabs %}
-
-```powershell#PowerShell/cmd.exe
-> powershell -c "irm bun.sh/install.ps1|iex"
-```
-
-```powershell#npm
-> npm install -g bun # the last `npm` command you'll ever need
-```
-
-```powershell#Scoop
-> scoop install bun
-```
-
-{% /codetabs %}
-
-{% callout %}
-Bun requires a minimum of Windows 10 version 1809
-{% /callout %}
-
-For support and discussion, please join the [#windows channel on our Discord](http://bun.com/discord).
-
-## Docker
-
-Bun provides a [Docker image](https://hub.docker.com/r/oven/bun/tags) that supports both Linux x64 and arm64.
-
-```bash
-$ docker pull oven/bun
-$ docker run --rm --init --ulimit memlock=-1:-1 oven/bun
-```
-
-There are also image variants for different operating systems.
-
-```bash
-$ docker pull oven/bun:debian
-$ docker pull oven/bun:slim
-$ docker pull oven/bun:distroless
-$ docker pull oven/bun:alpine
-```
-
-## Checking installation
-
-To check that Bun was installed successfully, open a new terminal window and run `bun --version`.
-
-```sh
-$ bun --version
-1.x.y
-```
-
-To see the precise commit of [oven-sh/bun](https://github.com/oven-sh/bun) that you're using, run `bun --revision`.
-
-```sh
-$ bun --revision
-1.x.y+b7982ac13189
-```
-
-If you've installed Bun but are seeing a `command not found` error, you may have to manually add the installation directory (`~/.bun/bin`) to your `PATH`.
-
-### How to add your `PATH`
-
-{% details summary="Linux / Mac" %}
-First, determine what shell you're using:
-
-```sh
-$ echo $SHELL
-/bin/zsh # or /bin/bash or /bin/fish
-```
-
-Then add these lines below to bottom of your shell's configuration file.
-
-{% codetabs %}
-
-```bash#~/.zshrc
-# add to ~/.zshrc
-export BUN_INSTALL="$HOME/.bun"
-export PATH="$BUN_INSTALL/bin:$PATH"
-```
-
-```bash#~/.bashrc
-# add to ~/.bashrc
-export BUN_INSTALL="$HOME/.bun"
-export PATH="$BUN_INSTALL/bin:$PATH"
-```
-
-```sh#~/.config/fish/config.fish
-# add to ~/.config/fish/config.fish
-export BUN_INSTALL="$HOME/.bun"
-export PATH="$BUN_INSTALL/bin:$PATH"
-```
-
-{% /codetabs %}
-Save the file. You'll need to open a new shell/terminal window for the changes to take effect.
-
-{% /details %}
-
-{% details summary="Windows" %}
-First, determine if the bun binary is properly installed on your system:
-
-```pwsh
-& "$env:USERPROFILE\.bun\bin\bun" --version
-```
-
-If the command runs successfully but `bun --version` is not recognized, it means that bun is not in your system's `PATH`. To fix this, open a Powershell terminal and run the following command:
-
-```pwsh
-[System.Environment]::SetEnvironmentVariable(
-    "Path",
-    [System.Environment]::GetEnvironmentVariable("Path", "User") + ";$env:USERPROFILE\.bun\bin",
-    [System.EnvironmentVariableTarget]::User
-)
-```
-
-After running the command, restart your terminal and test with `bun --version`
-
-{% /details %}
-
-## Upgrading
-
-Once installed, the binary can upgrade itself.
-
-```sh
-$ bun upgrade
-```
-
-{% callout %}
-**Homebrew users** — To avoid conflicts with Homebrew, use `brew upgrade bun` instead.
-
-**Scoop users** — To avoid conflicts with Scoop, use `scoop update bun` instead.
-
-{% /callout %}
-
-## Canary builds
-
-Bun automatically releases an (untested) canary build on every commit to `main`. To upgrade to the latest canary build:
-
-```sh
-$ bun upgrade --canary
-```
-
-The canary build is useful for testing new features and bug fixes before they're released in a stable build. To help the Bun team fix bugs faster, canary builds automatically upload crash reports to Bun's team.
-
-[View canary build](https://github.com/oven-sh/bun/releases/tag/canary)
-
-{% callout %}
-**Note** — To switch back to a stable release from canary, run `bun upgrade --stable`.
-{% /callout %}
-
-## Installing older versions of Bun
-
-Since Bun is a single binary, you can install older versions of Bun by re-running the installer script with a specific version.
-
-### Installing a specific version of Bun on Linux/Mac
-
-To install a specific version of Bun, you can pass the git tag of the version you want to install to the install script, such as `bun-v1.2.0` or `bun-v1.3.2-canary.20251105T140650`.
-
-```sh
-$ curl -fsSL https://bun.com/install | bash -s "bun-v1.3.2-canary.20251105T140650"
-```
-
-### Installing a specific version of Bun on Windows
-
-On Windows, you can install a specific version of Bun by passing the version number to the Powershell install script.
-
-```sh
-# PowerShell:
-$ iex "& {$(irm https://bun.com/install.ps1)} -Version 1.3.2-canary.20251105T140650"
-```
-
-## Downloading Bun binaries directly
-
-To download Bun binaries directly, you can visit the [releases page](https://github.com/oven-sh/bun/releases) on GitHub.
-
-For convenience, here are download links for the latest version:
-
-- [`bun-linux-x64.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-x64.zip)
-- [`bun-linux-x64-baseline.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-x64-baseline.zip)
-- [`bun-linux-x64-musl.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-x64-musl.zip)
-- [`bun-linux-x64-musl-baseline.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-x64-musl-baseline.zip)
-- [`bun-windows-x64.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-windows-x64.zip)
-- [`bun-windows-x64-baseline.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-windows-x64-baseline.zip)
-- [`bun-darwin-aarch64.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-darwin-aarch64.zip)
-- [`bun-linux-aarch64.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-aarch64.zip)
-- [`bun-linux-aarch64-musl.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-linux-aarch64-musl.zip)
-- [`bun-darwin-x64.zip`](https://github.com/oven-sh/bun/releases/latest/download/bun-darwin-x64.zip)
-
-The `musl` binaries are built for distributions that do not ship with the glibc libraries by default, instead relying on musl. The two most popular distros are Void Linux and Alpine Linux, with the latter is used heavily in Docker containers. If you encounter an error like the following: `bun: /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.29' not found (required by bun)`, try using the musl binary. Bun's install script automatically chooses the correct binary for your system.
-
-### CPU requirements and `baseline` builds
-
-Bun's `x64` binaries target the Haswell CPU architecture, which means they require AVX and AVX2 instructions. For Linux and Windows, the `x64-baseline` binaries are also available which target the Nehalem architecture. If you run into an "Illegal Instruction" error when running Bun, try using the `baseline` binaries instead. Bun's install script automatically chooses the correct binary for your system which helps avoid this issue. Baseline builds are slower than regular builds, so use them only if necessary.
-
-| Build        | Intel requirement                                                  | AMD requirement    |
-| ------------ | ------------------------------------------------------------------ | ------------------ |
-| x64          | Haswell (4th generation Core) or newer, except some low-end models | Excavator or newer |
-| x64-baseline | Nehalem (1st generation Core) or newer                             | Bulldozer or newer |
-
-Bun does not currently support any CPUs older than the `baseline` target, which mandates the SSE4.2 extension.
-
-Bun also publishes `darwin-x64-baseline` binaries, but these are just a copy of the `darwin-x64` ones so they still have the same CPU requirement. We only maintain these since some tools expect them to exist. Bun requires macOS 13.0 or later, which does not support any CPUs that don't meet our requirement.
-
-<!--
-## Native
-
-Works on macOS x64 & Silicon, Linux x64, Windows Subsystem for Linux.
-
-```sh
-$ curl -fsSL https://bun.com/install | bash
-```
-
-Once installed, the binary can upgrade itself.
-
-```sh
-$ bun upgrade
-```
-
-Bun automatically releases an (untested) canary build on every commit to `main`. To upgrade to the latest canary build:
-
-```sh
-$ bun upgrade --canary
-```
-
-## Homebrew
-
-Works on macOS and Linux
-
-```sh
-$ brew tap oven-sh/bun
-$ brew install bun
-```
-
-Homebrew recommends using `brew upgrade <package>` to install newer versions.
-
-## Docker
-
-Works on Linux x64
-
-```sh
-# this is a comment
-$ docker pull oven/bun:edge
-this is some output
-$ docker run --rm --init --ulimit memlock=-1:-1 oven/bun:edge
-$ docker run --rm --init --ulimit memlock=-1:-1 oven/bun:edge
-this is some output
-``` -->
-
-<!-- ## Completions
-
-Shell auto-completion should be configured automatically when Bun is installed!
-
-If not, run the following command. It uses `$SHELL` to determine which shell you're using and writes a completion file to the appropriate place on disk. It's automatically re-run on every `bun upgrade`.
-
-```bash
-$ bun completions
-```
-
-To write the completions to a custom location:
-
-```bash
-$ bun completions > path-to-file      # write to file
-$ bun completions /path/to/directory  # write into directory
-``` -->
-
-## Uninstall
-
-If you need to remove Bun from your system, use the following commands.
-
-{% codetabs %}
-
-```bash#macOS/Linux_(curl)
-$ rm -rf ~/.bun # for macOS, Linux, and WSL
-```
-
-```powershell#Windows
-> powershell -c ~\.bun\uninstall.ps1
-```
-
-```powershell#Scoop
-> scoop uninstall bun
-```
-
-```bash#npm
-$ npm uninstall -g bun
-```
-
-```bash#Homebrew
-$ brew uninstall bun
-```
-
-{% /codetabs %}