add support for "workspaces.nohoist" and "workspaces.hoistingLimits"

[dylan-conway]

What does this PR do?

Adds support for "workspaces.nohoist" and "workspaces.hoistingLimits" in bun install.

{
    "name": "hoisting-settings",
    "workspaces": {
        "nohoist": ["pkg1/react", "pkg2/**", "**/react"],
        "hoistingLimits": "dependencies", // or "workspaces" or "none"
        "packages": ["pkg1", "pkg2"]
    },
    "dependencies": {
        "react": "^18"
    }
}

closes #6850

"nohoist"

The "nohoist" field prevents a package from hoisting if any of the specified patterns match it's package path. The patterns support glob syntax. Example:

package.json

{
    "name": "nohoist-react",
    "workspaces": {
        "packages": [
            "pkg1"
        ],
        "nohoist": [
            "pkg1/react"
        ]
    }
}

pkg1/package.json:

{
    "name": "pkg1",
    "dependencies": {
        "react": "18.3.1"
    }
}

This package.json will prevent [email protected] from hoisting out of pkg1. The transitive dependencies of react are still able to hoist to the root. The result of an install would be:

./node_modules
├── [email protected]
├── [email protected]
└── pkg1@workspace:pkg1
    └── [email protected]

If you wanted to prevent react and all it's dependencies from hoisting, "pkg1/react/**" could be added to nohoist:

  "nohoist": [
+   "pkg1/react/**",
    "pkg1/react"
  }

An install would create:

./node_modules
└── pkg1@workspace:pkg1
    └── [email protected]
        └── [email protected]
            └── [email protected]

"hoistingLimits"

The "hoistingLimits" field allows limiting dependency hoisting to workspaces or the direct dependencies of workspaces. There are three valid values: "none", "workspaces", and "dependencies".

"none"

This is the default value. No limitation, all dependencies are allowed to hoist like they normally are.

"workspaces"

Prevents dependencies from hoisting out of workspaces. Example:

package.json

{
    "name": "hoisting-limits-workspaces",
    "workspaces": {
        "packages": ["pkg1", "pkg2"],
        "hoistingLimits": "workspaces"
    }
}

pkg1/package.json

{
    "name": "pkg1",
    "dependencies": {
        "react": "18.3.1"
    }
}

pkg2/package.json

{
    "name": "pkg2",
    "dependencies": {
        "react": "18.3.1"
    }
}

pkg1 and pkg2 both depend on the same version of react, and setting "hoistingLimits": "workspaces" will prevent react and it's transitive dependencies from hoisting beyond their workspaces, resulting in separate copies of these packages. An installs creates:

./node_modules
├── pkg1@workspace:pkg1
│   ├── [email protected]
│   ├── [email protected]
│   └── [email protected]
└── pkg2@workspace:pkg2
    ├── [email protected]
    ├── [email protected]
    └── [email protected]

"dependencies"

"dependencies" does the same as "workspaces" and additionally prevents transitive dependencies from hoisting beyond direct dependencies. This can be used to prevent phantom dependencies. With the same example with pkg1 and pkg2, an install with "hoistingLimits": "dependencies" would create:

./node_modules
├── pkg1@workspace:pkg1
│   └── [email protected]
│       ├── [email protected]
│       └── [email protected]
└── pkg2@workspace:pkg2
    └── [email protected]
        ├── [email protected]
        └── [email protected]

How did you verify your code works?

TODO:

• root package nohoist patterns
• matching packages in a workspace
• match transitive dependency of a hoisted dependency
• test adding/removing patterns from nohoist across multiple installs
• match all packages
• find out why webpack-cli and "nohoist": ["**"] hangs
• text and binary lockfile serialize/deserialize nohoist array correctly

[robobun]

^{Updated 1:11 PM PT - Jun 3rd, 2025}

❌ @dylan-conway, your commit 504b433 has 4 failures in Build #18047:

• test/napi/napi.test.ts - 1 failing on 🐧 20.04 x64-baseline
• test/js/third_party/@duckdb/node-api/duckdb.test.ts - segmentation fault on 🐧 12 x64-baseline
• test/js/node/test/parallel/test-net-bytes-stats.js - code 1 on 🍎 13 aarch64
• test/js/bun/spawn/spawn.test.ts - 1 failing on 🪟 2019 x64-baseline
• test/js/bun/spawn/spawn.test.ts - 1 failing on 🪟 2019 x64

---

🧪   To try this PR locally:

bunx bun-pr 20124

That installs a local version of the PR into your bun-20124 executable, so you can run:

bun-20124 --bun

[dylan-conway]

This pr was reverted and reopened here #20178