fix(install): link a local workspace member's bin into node_modules/.bin

[nathanwhitbot]

Closes #36313.

A local workspace member declaring bin in its package.json was symlinked into node_modules/<name>, but never got a node_modules/.bin entry — so deno task --cwd apps/web cli failed with local-cli: command not found. External npm dependencies with bins worked fine.

Root cause

Workspace members are not part of the npm resolution snapshot. Every code path that creates a .bin entry is keyed on &NpmResolutionPackage + NpmPackageExtraInfo (libs/npm_installer/bin_entries.rs), and deno task's managed-resolver command lookup (resolve_managed_npm_commands) only walks snapshot.top_level_packages(). Members were invisible to both. The doc comment on local.rs::setup_member_bin_entries stated the gap outright.

Fix

Installer — InstallWorkspacePkg now carries a parsed bin. deno_package_json::PackageJson only exposes bin as a raw serde_json::Value, so the String and Map shapes are parsed in package_json_to_bin_entry. resolve_workspace_bin_packages builds a synthetic NpmResolutionPackage per non-root member — the same precedent as the existing resolve_workspace_lifecycle_packages — and add_workspace_bin_entries pushes them into the same BinEntries as snapshot packages just before finish(). They are added last, so a real dependency wins any name collision. Wired through both linkers: isolated/pnpm-style (local.rs) and hoisted (hoisted.rs).

Task runner — the managed branch of resolve_task_node_modules_bin_dirs now walks cwd ancestors up to the root node_modules parent, and resolve_custom_commands merges those .bin entries. Prepending to PATH alone is not sufficient: on Windows the shims are plain <name> / .cmd / .ps1 files, and a #!/usr/bin/env node shebang would otherwise exec real node rather than deno.

Only entries classified as BinValue::JsFile are merged into custom commands; Executable entries (shell scripts, native binaries) are left to PATH, where deno_task_shell honours the shebang. Routing those through deno run --ext=js would SyntaxError. Names of skipped Executable entries are still recorded so a farther bin dir can't re-classify the same name as JsFile and win, which would invert closest-first precedence.

Pruning — calculate_packages_hash previously hashed only snapshot ids and remote packages, so member bins never tripped cleanup_unused_packages, leaving stale/dangling root .bin entries when a member's bin changed. The hoisted linker had no hash gate at all and cleanup_hoisted_packages skips dot-prefixed dirs, so it wipes the root .bin explicitly.

Notes for reviewers

Chmod side effect. The root .bin entry points at the member's real source directory, not the node_modules/<name> symlink (that symlink is created later in the install). So make_executable_if_exists chmods the user's git-tracked script +x (100644 → 100755), which will show up as a mode change in git status. npm's bin-links does the same thing, so this matches ecosystem behaviour, but it's worth being aware of.

Known precedence exception, documented not fixed. Closest-first holds among the bin dirs, but the command map is pre-seeded from the snapshot's top-level packages, so a root dependency's bin beats a nearer workspace member's bin of the same name — the opposite of npm/pnpm. This is pre-existing behaviour affecting every managed task, and reordering it reaches well beyond workspaces, so it's documented in resolve_custom_commands with a pointer to the TODO(nathanwhit) on resolve_managed_npm_commands where the real fix belongs.

BYONM/managed asymmetry. The BYONM branch deliberately routes every entry through deno run, including Executable ones, because a JS bin with no shebang classifies as Executable and running it through deno is the only thing that makes it work there. Under the managed resolver such a bin falls through to PATH and fails to exec on unix — same as npm/node, which also produce a non-executable shim target in that case. Pinned by the root-noshebang step of tests/specs/workspaces/workspace_member_bin.

Collision warning is gated on clean_on_install so it isn't reprinted ahead of every deno task re-link; the cost is that a user who only ever tasks against an already-linked node_modules won't see it.

Tests

50 unit tests in deno_npm_installer, plus 9 spec tests under tests/specs/workspaces/: the issue's exact repro on both linkers (workspace_member_bin, _hoisted), the string form of bin and scoped member names (_string), member-vs-member and dependency-claimed collisions (_collision, _duplicate, _dep_claim), stale-entry pruning on both linkers (_prune, _prune_hoisted), and shell-script/no-shebang shadowing (_shadow). specs::task (128) stays green.

[nathanwhitbot]

Pushed a test-only fix for the macOS spec failure (specs::workspaces::workspace_member_bin).

The root-noshebang step asserted the text of the exec failure for a .bin entry left to PATH. On Linux that's Exec format error; on macOS the spawn falls back to running the file with /bin/sh (execvp's ENOEXEC behaviour), so the JS source comes back as a pile of shell syntax errors instead — hence the failure on both macOS runners. The thing the step actually asserts (a no-shebang JS bin is not routed through deno run under the managed resolver) holds identically on both, so the step is now "if": "linux" with a comment explaining the divergence. No product code changed; all 9 workspace_member_bin* specs pass locally.