Summary
When bb plugin new's scaffold install fails, the CLI prints only Could not run npm install — run it in the plugin directory before \bb plugin build``. npm's own output — which is the entire diagnosis — is discarded, so the author has to rerun the same failing command by hand to read what the CLI already had.
Versions and environment
- bb 0.40.0, desktop app. Source at
ad79bbb5ec909524f8f281e62d860c588a86f332.
- macOS 15 (Darwin 25.3.0), arm64. Node v20.13.1, npm 10.5.2.
Steps to reproduce
Any npm failure reproduces it. The one I hit was an unwritable npm cache (agent sandbox):
bb plugin new probe- npm exits non-zero with
npm error code EPERM / npm error syscall open / npm error Your cache folder contains root-owned files.
Expected vs actual
Actual:
Could not run npm install — run it in the plugin directory before `bb plugin build`.
Expected: the same line, followed by npm's own explanation, so the next step is obvious without a second run.
Evidence
The catch discards cause entirely:
|
} catch { |
|
console.warn( |
|
"Could not run npm install — run it in the plugin directory before `bb plugin build`.", |
|
); |
|
return false; |
|
} |
execFile rejects with stdout/stderr attached, so the information is present and dropped.
What you ruled out
- Not the separate registry-probe warning:
could not reach the npm registry … is a different code path and did fire; it says nothing about why the install itself failed.
- Not covered by the existing tests:
plugin-new.test.ts only exercises npm missing from PATH, which produces no output to pass through.
Suggested priority and effort
Small, but it is the first command a plugin author runs, and the failure is common in sandboxed or proxied environments. A few lines plus a fake-npm mode in the existing test seam.
AGENT GENERATED
Summary
When
bb plugin new's scaffold install fails, the CLI prints onlyCould not run npm install — run it in the plugin directory before \bb plugin build``. npm's own output — which is the entire diagnosis — is discarded, so the author has to rerun the same failing command by hand to read what the CLI already had.Versions and environment
ad79bbb5ec909524f8f281e62d860c588a86f332.Steps to reproduce
Any npm failure reproduces it. The one I hit was an unwritable npm cache (agent sandbox):
bb plugin new probenpm error code EPERM / npm error syscall open / npm error Your cache folder contains root-owned files.Expected vs actual
Actual:
Expected: the same line, followed by npm's own explanation, so the next step is obvious without a second run.
Evidence
The catch discards
causeentirely:bb/apps/cli/src/commands/plugin.ts
Lines 499 to 504 in ad79bbb
execFilerejects withstdout/stderrattached, so the information is present and dropped.What you ruled out
could not reach the npm registry …is a different code path and did fire; it says nothing about why the install itself failed.plugin-new.test.tsonly exercises npm missing from PATH, which produces no output to pass through.Suggested priority and effort
Small, but it is the first command a plugin author runs, and the failure is common in sandboxed or proxied environments. A few lines plus a fake-npm mode in the existing test seam.