bun-types 1.2.19-canary.20250717T140556 → 1.2.19-canary.20250719T140529

package/docs/api/fetch.md

@@ -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.20250717T140556
+[fetch] > User-Agent: Bun/1.2.19-canary.20250719T140529
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br

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.20250717T140556\n"
+console.log(text); // => "1.2.19-canary.20250719T140529\n"
 ```
 
 Configure the output stream by passing one of the following values to `stdout/stderr`:

package/docs/bundler/executables.md

@@ -88,6 +88,20 @@ The order of the `--target` flag does not matter, as long as they're delimited b
 
 On x64 platforms, Bun uses SIMD optimizations which require a modern CPU supporting AVX2 instructions. The `-baseline` build of Bun is for older CPUs that don't support these optimizations. Normally, when you install Bun we automatically detect which version to use but this can be harder to do when cross-compiling since you might not know the target CPU. You usually don't need to worry about it on Darwin x64, but it is relevant for Windows x64 and Linux x64. If you or your users see `"Illegal instruction"` errors, you might need to use the baseline version.
 
+## Build-time constants
+
+Use the `--define` flag to inject build-time constants into your executable, such as version numbers, build timestamps, or configuration values:
+
+```bash
+$ bun build --compile --define BUILD_VERSION='"1.2.3"' --define BUILD_TIME='"2024-01-15T10:30:00Z"' src/cli.ts --outfile mycli
+```
+
+These constants are embedded directly into your compiled binary at build time, providing zero runtime overhead and enabling dead code elimination optimizations.
+
+{% callout type="info" %}
+For comprehensive examples and advanced patterns, see the [Build-time constants guide](/guides/runtime/build-time-constants).
+{% /callout %}
+
 ## Deploying to production
 
 Compiled executables reduce memory usage and improve Bun's start time.

package/docs/cli/install.md

@@ -183,6 +183,30 @@ Bun supports installing dependencies from Git, GitHub, and local or remotely-hos
 }
 ```
 
+## Installation strategies
+
+Bun supports two package installation strategies that determine how dependencies are organized in `node_modules`:
+
+### Hoisted installs (default for single projects)
+
+The traditional npm/Yarn approach that flattens dependencies into a shared `node_modules` directory:
+
+```bash
+$ bun install --linker hoisted
+```
+
+### Isolated installs
+
+A pnpm-like approach that creates strict dependency isolation to prevent phantom dependencies:
+
+```bash
+$ bun install --linker isolated
+```
+
+Isolated installs create a central package store in `node_modules/.bun/` with symlinks in the top-level `node_modules`. This ensures packages can only access their declared dependencies.
+
+For complete documentation on isolated installs, refer to [Package manager > Isolated installs](https://bun.com/docs/install/isolated).
+
 ## Configuration
 
 The default behavior of `bun install` can be configured in `bunfig.toml`. The default values are shown below.
@@ -213,6 +237,10 @@ dryRun = false
 
 # equivalent to `--concurrent-scripts` flag
 concurrentScripts = 16 # (cpu count or GOMAXPROCS) x2
+
+# installation strategy: "hoisted" or "isolated"
+# default: "hoisted"
+linker = "hoisted"
 ```
 
 ## CI/CD

package/docs/cli/pm.md

@@ -213,7 +213,7 @@ To display current package version and help:
 
 ```bash
 $ bun pm version
-bun pm version v1.2.19-canary.20250717T140556 (ca7428e9)
+bun pm version v1.2.19-canary.20250719T140529 (ca7428e9)
 Current package version: v1.0.0
 
 Increment:

package/docs/cli/publish.md

@@ -7,7 +7,7 @@ Use `bun publish` to publish a package to the npm registry.
 $ bun publish
 
 ## Output
-bun publish v1.2.19-canary.20250717T140556 (ca7428e9)
+bun publish v1.2.19-canary.20250719T140529 (ca7428e9)
 
 packed 203B package.json
 packed 224B README.md

package/docs/cli/test.md

@@ -248,4 +248,33 @@ $ bun test foo
 
 Any test file in the directory with an _absolute path_ that contains one of the targets will run. Glob patterns are not yet supported. -->
 
+## AI Agent Integration
+
+When using Bun's test runner with AI coding assistants, you can enable quieter output to improve readability and reduce context noise. This feature minimizes test output verbosity while preserving essential failure information.
+
+### Environment Variables
+
+Set any of the following environment variables to enable AI-friendly output:
+
+- `CLAUDECODE=1` - For Claude Code
+- `REPL_ID=1` - For Replit
+- `AGENT=1` - Generic AI agent flag
+
+### Behavior
+
+When an AI agent environment is detected:
+
+- Only test failures are displayed in detail
+- Passing, skipped, and todo test indicators are hidden
+- Summary statistics remain intact
+
+```bash
+# Example: Enable quiet output for Claude Code
+$ CLAUDECODE=1 bun test
+
+# Still shows failures and summary, but hides verbose passing test output
+```
+
+This feature is particularly useful in AI-assisted development workflows where reduced output verbosity improves context efficiency while maintaining visibility into test failures.
+
 {% bunCLIUsage command="test" /%}

package/docs/guides/ecosystem/nuxt.md

@@ -9,7 +9,7 @@ $ bunx nuxi init my-nuxt-app
 ✔ Which package manager would you like to use?
 bun
 ◐ Installing dependencies...
-bun install v1.2.19-canary.20250717T140556 (16b4bf34)
+bun install v1.2.19-canary.20250719T140529 (16b4bf34)
  + @nuxt/devtools@0.8.2
  + nuxt@3.7.0
  785 packages installed [2.67s]

package/docs/guides/install/add-peer.md

@@ -15,7 +15,7 @@ This will add the package to `peerDependencies` in `package.json`.
 ```json-diff
 {
   "peerDependencies": {
-+   "@types/bun": "^1.2.19-canary.20250717T140556"
++   "@types/bun": "^1.2.19-canary.20250719T140529"
   }
 }
 ```
@@ -27,7 +27,7 @@ Running `bun install` will install peer dependencies by default, unless marked o
 ```json-diff
 {
   "peerDependencies": {
-    "@types/bun": "^1.2.19-canary.20250717T140556"
+    "@types/bun": "^1.2.19-canary.20250719T140529"
   },
   "peerDependenciesMeta": {
 +   "@types/bun": {

package/docs/guides/install/from-npm-install-to-bun-install.md

@@ -97,7 +97,7 @@ $ bun update
 $ bun update @types/bun --latest
 
 # Update a dependency to a specific version
-$ bun update @types/bun@1.2.19-canary.20250717T140556
+$ bun update @types/bun@1.2.19-canary.20250719T140529
 
 # Update all dependencies to the latest versions
 $ bun update --latest

package/docs/guides/runtime/build-time-constants.md

@@ -0,0 +1,293 @@
+---
+name: Build-time constants with --define
+---
+
+The `--define` flag can be used with `bun build` and `bun build --compile` to inject build-time constants into your application. This is especially useful for embedding metadata like build versions, timestamps, or configuration flags directly into your compiled executables.
+
+```sh
+$ bun build --compile --define BUILD_VERSION='"1.2.3"' --define BUILD_TIME='"2024-01-15T10:30:00Z"' src/index.ts --outfile myapp
+```
+
+---
+
+## Why use build-time constants?
+
+Build-time constants are embedded directly into your compiled code, making them:
+
+- **Zero runtime overhead** - No environment variable lookups or file reads
+- **Immutable** - Values are baked into the binary at compile time
+- **Optimizable** - Dead code elimination can remove unused branches
+- **Secure** - No external dependencies or configuration files to manage
+
+This is similar to `gcc -D` or `#define` in C/C++, but for JavaScript/TypeScript.
+
+---
+
+## Basic usage
+
+### With `bun build`
+
+```sh
+# Bundle with build-time constants
+$ bun build --define BUILD_VERSION='"1.0.0"' --define NODE_ENV='"production"' src/index.ts --outdir ./dist
+```
+
+### With `bun build --compile`
+
+```sh
+# Compile to executable with build-time constants
+$ bun build --compile --define BUILD_VERSION='"1.0.0"' --define BUILD_TIME='"2024-01-15T10:30:00Z"' src/cli.ts --outfile mycli
+```
+
+### JavaScript API
+
+```ts
+await Bun.build({
+  entrypoints: ["./src/index.ts"],
+  outdir: "./dist",
+  define: {
+    BUILD_VERSION: '"1.0.0"',
+    BUILD_TIME: '"2024-01-15T10:30:00Z"',
+    DEBUG: "false",
+  },
+});
+```
+
+---
+
+## Common use cases
+
+### Version information
+
+Embed version and build metadata directly into your executable:
+
+{% codetabs %}
+
+```ts#src/version.ts
+// These constants are replaced at build time
+declare const BUILD_VERSION: string;
+declare const BUILD_TIME: string;
+declare const GIT_COMMIT: string;
+
+export function getVersion() {
+  return {
+    version: BUILD_VERSION,
+    buildTime: BUILD_TIME,
+    commit: GIT_COMMIT,
+  };
+}
+```
+
+```sh#Build command
+$ bun build --compile \
+  --define BUILD_VERSION='"1.2.3"' \
+  --define BUILD_TIME='"2024-01-15T10:30:00Z"' \
+  --define GIT_COMMIT='"abc123"' \
+  src/cli.ts --outfile mycli
+```
+
+{% /codetabs %}
+
+### Feature flags
+
+Use build-time constants to enable/disable features:
+
+```ts
+// Replaced at build time
+declare const ENABLE_ANALYTICS: boolean;
+declare const ENABLE_DEBUG: boolean;
+
+function trackEvent(event: string) {
+  if (ENABLE_ANALYTICS) {
+    // This entire block is removed if ENABLE_ANALYTICS is false
+    console.log("Tracking:", event);
+  }
+}
+
+if (ENABLE_DEBUG) {
+  console.log("Debug mode enabled");
+}
+```
+
+```sh
+# Production build - analytics enabled, debug disabled
+$ bun build --compile --define ENABLE_ANALYTICS=true --define ENABLE_DEBUG=false src/app.ts --outfile app-prod
+
+# Development build - both enabled
+$ bun build --compile --define ENABLE_ANALYTICS=false --define ENABLE_DEBUG=true src/app.ts --outfile app-dev
+```
+
+### Configuration
+
+Replace configuration objects at build time:
+
+```ts
+declare const CONFIG: {
+  apiUrl: string;
+  timeout: number;
+  retries: number;
+};
+
+// CONFIG is replaced with the actual object at build time
+const response = await fetch(CONFIG.apiUrl, {
+  timeout: CONFIG.timeout,
+});
+```
+
+```sh
+$ bun build --compile --define 'CONFIG={"apiUrl":"https://api.example.com","timeout":5000,"retries":3}' src/app.ts --outfile app
+```
+
+---
+
+## Advanced patterns
+
+### Environment-specific builds
+
+Create different executables for different environments:
+
+```json
+{
+  "scripts": {
+    "build:dev": "bun build --compile --define NODE_ENV='\"development\"' --define API_URL='\"http://localhost:3000\"' src/app.ts --outfile app-dev",
+    "build:staging": "bun build --compile --define NODE_ENV='\"staging\"' --define API_URL='\"https://staging.example.com\"' src/app.ts --outfile app-staging",
+    "build:prod": "bun build --compile --define NODE_ENV='\"production\"' --define API_URL='\"https://api.example.com\"' src/app.ts --outfile app-prod"
+  }
+}
+```
+
+### Using shell commands for dynamic values
+
+Generate build-time constants from shell commands:
+
+```sh
+# Use git to get current commit and timestamp
+$ bun build --compile \
+  --define BUILD_VERSION="\"$(git describe --tags --always)\"" \
+  --define BUILD_TIME="\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"" \
+  --define GIT_COMMIT="\"$(git rev-parse HEAD)\"" \
+  src/cli.ts --outfile mycli
+```
+
+### Build automation script
+
+Create a build script that automatically injects build metadata:
+
+```ts
+// build.ts
+import { $ } from "bun";
+
+const version = await $`git describe --tags --always`.text();
+const buildTime = new Date().toISOString();
+const gitCommit = await $`git rev-parse HEAD`.text();
+
+await Bun.build({
+  entrypoints: ["./src/cli.ts"],
+  outdir: "./dist",
+  define: {
+    BUILD_VERSION: JSON.stringify(version.trim()),
+    BUILD_TIME: JSON.stringify(buildTime),
+    GIT_COMMIT: JSON.stringify(gitCommit.trim()),
+  },
+});
+
+console.log(`Built with version ${version.trim()}`);
+```
+
+---
+
+## Important considerations
+
+### Value format
+
+Values must be valid JSON that will be parsed and inlined as JavaScript expressions:
+
+```sh
+# ✅ Strings must be JSON-quoted
+--define VERSION='"1.0.0"'
+
+# ✅ Numbers are JSON literals
+--define PORT=3000
+
+# ✅ Booleans are JSON literals
+--define DEBUG=true
+
+# ✅ Objects and arrays (use single quotes to wrap the JSON)
+--define 'CONFIG={"host":"localhost","port":3000}'
+
+# ✅ Arrays work too
+--define 'FEATURES=["auth","billing","analytics"]'
+
+# ❌ This won't work - missing quotes around string
+--define VERSION=1.0.0
+```
+
+### Property keys
+
+You can use property access patterns as keys, not just simple identifiers:
+
+```sh
+# ✅ Replace process.env.NODE_ENV with "production"
+--define 'process.env.NODE_ENV="production"'
+
+# ✅ Replace process.env.API_KEY with the actual key
+--define 'process.env.API_KEY="abc123"'
+
+# ✅ Replace nested properties
+--define 'window.myApp.version="1.0.0"'
+
+# ✅ Replace array access
+--define 'process.argv[2]="--production"'
+```
+
+This is particularly useful for environment variables:
+
+```ts
+// Before compilation
+if (process.env.NODE_ENV === "production") {
+  console.log("Production mode");
+}
+
+// After compilation with --define 'process.env.NODE_ENV="production"'
+if ("production" === "production") {
+  console.log("Production mode");
+}
+
+// After optimization
+console.log("Production mode");
+```
+
+### TypeScript declarations
+
+For TypeScript projects, declare your constants to avoid type errors:
+
+```ts
+// types/build-constants.d.ts
+declare const BUILD_VERSION: string;
+declare const BUILD_TIME: string;
+declare const NODE_ENV: "development" | "staging" | "production";
+declare const DEBUG: boolean;
+```
+
+### Cross-platform compatibility
+
+When building for multiple platforms, constants work the same way:
+
+```sh
+# Linux
+$ bun build --compile --target=bun-linux-x64 --define PLATFORM='"linux"' src/app.ts --outfile app-linux
+
+# macOS
+$ bun build --compile --target=bun-darwin-x64 --define PLATFORM='"darwin"' src/app.ts --outfile app-macos
+
+# Windows
+$ bun build --compile --target=bun-windows-x64 --define PLATFORM='"windows"' src/app.ts --outfile app-windows.exe
+```
+
+---
+
+## Related
+
+- [Define constants at runtime](/guides/runtime/define-constant) - Using `--define` with `bun run`
+- [Building executables](/bundler/executables) - Complete guide to `bun build --compile`
+- [Bundler API](/bundler) - Full bundler documentation including `define` option

package/docs/guides/test/run-tests.md

@@ -21,7 +21,7 @@ Here's what the output of a typical test run looks like. In this case, there are
 
 ```sh
 $ bun test
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test.test.js:
 ✓ add [0.87ms]
@@ -47,7 +47,7 @@ To only run certain test files, pass a positional argument to `bun test`. The ru
 
 ```sh
 $ bun test test3
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test3.test.js:
 ✓ add [1.40ms]
@@ -85,7 +85,7 @@ Adding `-t add` will only run tests with "add" in the name. This works with test
 
 ```sh
 $ bun test -t add
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test.test.js:
 ✓ add [1.79ms]

package/docs/guides/test/snapshot.md

@@ -18,7 +18,7 @@ The first time this test is executed, Bun will evaluate the value passed into `e
 
 ```sh
 $ bun test test/snap
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [1.48ms]
@@ -61,7 +61,7 @@ Later, when this test file is executed again, Bun will read the snapshot file an
 
 ```sh
 $ bun test
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [1.05ms]
@@ -78,7 +78,7 @@ To update snapshots, use the `--update-snapshots` flag.
 
 ```sh
 $ bun test --update-snapshots
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [0.86ms]

package/docs/guides/test/update-snapshots.md

@@ -29,7 +29,7 @@ To regenerate snapshots, use the `--update-snapshots` flag.
 
 ```sh
 $ bun test --update-snapshots
-bun test v1.2.19-canary.20250717T140556 (9c68abdb)
+bun test v1.2.19-canary.20250719T140529 (9c68abdb)
 
 test/snap.test.ts:
 ✓ snapshot [0.86ms]

package/docs/guides/util/version.md

@@ -5,7 +5,7 @@ name: Get the current Bun version
 Get the current version of Bun in a semver format.
 
 ```ts#index.ts
-Bun.version; // => "1.2.19-canary.20250717T140556"
+Bun.version; // => "1.2.19-canary.20250719T140529"
 ```
 
 ---

package/docs/install/index.md

@@ -81,6 +81,14 @@ $ bun install --verbose # debug logging
 $ bun install --silent  # no logging
 ```
 
+To use isolated installs instead of the default hoisted strategy:
+
+```bash
+$ bun install --linker isolated
+```
+
+Isolated installs create strict dependency isolation similar to pnpm, preventing phantom dependencies and ensuring more deterministic builds. For complete documentation, see [Isolated installs](https://bun.com/docs/install/isolated).
+
 {% details summary="Configuring behavior" %}
 The default behavior of `bun install` can be configured in `bunfig.toml`:
 
@@ -110,6 +118,10 @@ dryRun = false
 
 # equivalent to `--concurrent-scripts` flag
 concurrentScripts = 16 # (cpu count or GOMAXPROCS) x2
+
+# installation strategy: "hoisted" or "isolated"
+# default: "hoisted"
+linker = "hoisted"
 ```
 
 {% /details %}

package/docs/install/isolated.md

@@ -0,0 +1,195 @@
+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.
+
+## 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.
+
+### Key benefits
+
+- **Prevents phantom dependencies** — Packages cannot accidentally import dependencies they haven't declared
+- **Deterministic resolution** — Same dependency tree regardless of what else is installed
+- **Better for monorepos** — Workspace isolation prevents cross-contamination between packages
+- **Reproducible builds** — More predictable resolution behavior across environments
+
+## Using isolated installs
+
+### Command line
+
+Use the `--linker` flag to specify the installation strategy:
+
+```bash
+# Use isolated installs
+$ bun install --linker isolated
+
+# Use traditional hoisted installs
+$ bun install --linker hoisted
+```
+
+### Configuration file
+
+Set the default linker strategy in your `bunfig.toml`:
+
+```toml
+[install]
+linker = "isolated"
+```
+
+### Default behavior
+
+By default, Bun uses the **hoisted** installation strategy for all projects. To use isolated installs, you must explicitly specify the `--linker isolated` flag or set it in your configuration file.
+
+## How isolated installs work
+
+### Directory structure
+
+Instead of hoisting dependencies, isolated installs create a two-tier structure:
+
+```
+node_modules/
+├── .bun/                          # Central package store
+│   ├── package@1.0.0/             # Versioned package installations
+│   │   └── node_modules/
+│   │       └── package/           # Actual package files
+│   ├── @scope+package@2.1.0/      # Scoped packages (+ replaces /)
+│   │   └── node_modules/
+│   │       └── @scope/
+│   │           └── package/
+│   └── ...
+└── package-name -> .bun/package@1.0.0/node_modules/package  # Symlinks
+```
+
+### Resolution algorithm
+
+1. **Central store** — All packages are installed in `node_modules/.bun/package@version/` directories
+2. **Symlinks** — Top-level `node_modules` contains symlinks pointing to the central store
+3. **Peer resolution** — Complex peer dependencies create specialized directory names
+4. **Deduplication** — Packages with identical package IDs and peer dependency sets are shared
+
+### Workspace handling
+
+In monorepos, workspace dependencies are handled specially:
+
+- **Workspace packages** — Symlinked directly to their source directories, not the store
+- **Workspace dependencies** — Can access other workspace packages in the monorepo
+- **External dependencies** — Installed in the isolated store with proper isolation
+
+## Comparison with hoisted installs
+
+| Aspect                    | Hoisted (npm/Yarn)                         | Isolated (pnpm-like)                    |
+| ------------------------- | ------------------------------------------ | --------------------------------------- |
+| **Dependency access**     | Packages can access any hoisted dependency | Packages only see declared dependencies |
+| **Phantom dependencies**  | ❌ Possible                                | ✅ Prevented                            |
+| **Disk usage**            | ✅ Lower (shared installs)                 | ✅ Similar (uses symlinks)              |
+| **Determinism**           | ❌ Less deterministic                      | ✅ More deterministic                   |
+| **Node.js compatibility** | ✅ Standard behavior                       | ✅ Compatible via symlinks              |
+| **Best for**              | Single projects, legacy code               | Monorepos, strict dependency management |
+
+## Advanced features
+
+### Peer dependency handling
+
+Isolated installs handle peer dependencies through sophisticated resolution:
+
+```bash
+# Package with peer dependencies creates specialized paths
+node_modules/.bun/package@1.0.0_react@18.2.0/
+```
+
+The directory name encodes both the package version and its peer dependency versions, ensuring each unique combination gets its own installation.
+
+### Backend strategies
+
+Bun uses different file operation strategies for performance:
+
+- **Clonefile** (macOS) — Copy-on-write filesystem clones for maximum efficiency
+- **Hardlink** (Linux/Windows) — Hardlinks to save disk space
+- **Copyfile** (fallback) — Full file copies when other methods aren't available
+
+### Debugging isolated installs
+
+Enable verbose logging to understand the installation process:
+
+```bash
+$ bun install --linker isolated --verbose
+```
+
+This shows:
+
+- Store entry creation
+- Symlink operations
+- Peer dependency resolution
+- Deduplication decisions
+
+## Troubleshooting
+
+### Compatibility issues
+
+Some packages may not work correctly with isolated installs due to:
+
+- **Hardcoded paths** — Packages that assume a flat `node_modules` structure
+- **Dynamic imports** — Runtime imports that don't follow Node.js resolution
+- **Build tools** — Tools that scan `node_modules` directly
+
+If you encounter issues, you can:
+
+1. **Switch to hoisted mode** for specific projects:
+
+   ```bash
+   $ bun install --linker hoisted
+   ```
+
+2. **Report compatibility issues** to help improve isolated install support
+
+### Performance considerations
+
+- **Install time** — May be slightly slower due to symlink operations
+- **Disk usage** — Similar to hoisted (uses symlinks, not file copies)
+- **Memory usage** — Higher during install due to complex peer resolution
+
+## Migration guide
+
+### From npm/Yarn
+
+```bash
+# Remove existing node_modules and lockfiles
+$ rm -rf node_modules package-lock.json yarn.lock
+
+# Install with isolated linker
+$ bun install --linker isolated
+```
+
+### From pnpm
+
+Isolated installs are conceptually similar to pnpm, so migration should be straightforward:
+
+```bash
+# Remove pnpm files
+$ rm -rf node_modules pnpm-lock.yaml
+
+# Install with Bun's isolated linker
+$ 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
+
+**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
+
+**Use hoisted installs when:**
+
+- Working with legacy code that assumes flat `node_modules`
+- Compatibility with existing build tools is required
+- Working in environments where symlinks aren't well supported
+- You prefer the simpler traditional npm behavior
+
+## 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/docs/installation.md

@@ -14,7 +14,7 @@ Kernel version 5.6 or higher is strongly recommended, but the minimum is 5.1. Us
 ```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.2.19-canary.20250717T140556"
+$ curl -fsSL https://bun.com/install | bash -s "bun-v1.2.19-canary.20250719T140529"
 ```
 
 ```bash#npm
@@ -189,10 +189,10 @@ Since Bun is a single binary, you can install older versions of Bun by re-runnin
 
 ### 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.2.19-canary.20250717T140556`.
+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.2.19-canary.20250719T140529`.
 
 ```sh
-$ curl -fsSL https://bun.com/install | bash -s "bun-v1.2.19-canary.20250717T140556"
+$ curl -fsSL https://bun.com/install | bash -s "bun-v1.2.19-canary.20250719T140529"
 ```
 
 ### Installing a specific version of Bun on Windows
@@ -201,7 +201,7 @@ On Windows, you can install a specific version of Bun by passing the version num
 
 ```sh
 # PowerShell:
-$ iex "& {$(irm https://bun.com/install.ps1)} -Version 1.2.19-canary.20250717T140556"
+$ iex "& {$(irm https://bun.com/install.ps1)} -Version 1.2.19-canary.20250719T140529"
 ```
 
 ## Downloading Bun binaries directly

package/docs/runtime/debugger.md

@@ -124,11 +124,11 @@ await fetch("https://example.com", {
 This prints the `fetch` request as a single-line `curl` command to let you copy-paste into your terminal to replicate the request.
 
 ```sh
-[fetch] $ curl --http1.1 "https://example.com/" -X POST -H "content-type: application/json" -H "Connection: keep-alive" -H "User-Agent: Bun/1.2.19-canary.20250717T140556" -H "Accept: */*" -H "Host: example.com" -H "Accept-Encoding: gzip, deflate, br" --compressed -H "Content-Length: 13" --data-raw "{\"foo\":\"bar\"}"
+[fetch] $ curl --http1.1 "https://example.com/" -X POST -H "content-type: application/json" -H "Connection: keep-alive" -H "User-Agent: Bun/1.2.19-canary.20250719T140529" -H "Accept: */*" -H "Host: example.com" -H "Accept-Encoding: gzip, deflate, br" --compressed -H "Content-Length: 13" --data-raw "{\"foo\":\"bar\"}"
 [fetch] > HTTP/1.1 POST https://example.com/
 [fetch] > content-type: application/json
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.19-canary.20250717T140556
+[fetch] > User-Agent: Bun/1.2.19-canary.20250719T140529
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br
@@ -170,7 +170,7 @@ This prints the following to the console:
 [fetch] > HTTP/1.1 POST https://example.com/
 [fetch] > content-type: application/json
 [fetch] > Connection: keep-alive
-[fetch] > User-Agent: Bun/1.2.19-canary.20250717T140556
+[fetch] > User-Agent: Bun/1.2.19-canary.20250719T140529
 [fetch] > Accept: */*
 [fetch] > Host: example.com
 [fetch] > Accept-Encoding: gzip, deflate, br

package/docs/test/dom.md

@@ -55,7 +55,7 @@ Let's run this test with `bun test`:
 
 ```bash
 $ bun test
-bun test v1.2.19-canary.20250717T140556
+bun test v1.2.19-canary.20250719T140529
 
 dom.test.ts:
 ✓ dom test [0.82ms]

package/package.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.2.19-canary.20250717T140556",
+  "version": "1.2.19-canary.20250719T140529",
   "name": "bun-types",
   "license": "MIT",
   "types": "./index.d.ts",