Zoltan Kochan 3d143854c0 fix(exec.commands): fall back to alias as bin name when dlx slot lacks package.json (#11886) ...

`getBinName` reads the installed package's `package.json` out of the
GVS slot to discover the bin name. On CI this read has been failing
intermittently for `node@runtime:24.6.0` with
`ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND` — the dlx install reports
`added 1, done`, but the slot the symlink points at has no
`package.json`. The bin link itself is fine (pnpm creates it from the
resolution's `bin` info, not from the slot's manifest), so the only
casualty is `getBinName`.

The slot can end up without `package.json` when something populated it
without going through pnpm's `appendManifest` synthesis (or pacquet's
runtime-manifest synthesis equivalent) — runtime archives don't ship
their own `package.json`, so the synthesized one is the only way it
gets there. Pacquet's `import_indexed_dir` short-circuits on existing
slots without checking which files are present, so a slot populated
by an older code path stays incomplete.

Catch the manifest-not-found error and fall back to the scopeless
package name. For single-bin packages that match `manifest.bin` (the
common case for `pnpm dlx <pkg>`, including every `runtime:` spec),
this gives the same answer the manifest would. Multi-bin packages
already require `--package=<spec> <bin>` to disambiguate, which
short-circuits `getBinName` upstream and never enters this branch.

2026-05-23 21:42:27 +02:00

..

commands

fix(exec.commands): fall back to alias as bin name when dlx slot lacks package.json (#11886)

2026-05-23 21:42:27 +02:00

lifecycle

chore(release): 11.2.0 (#11764)

2026-05-20 12:41:09 +02:00

pnpm-cli-runner

chore(release): 11.1.3 (#11717)

2026-05-18 15:42:32 +02:00

prepare-package

chore(release): 11.2.0 (#11764)

2026-05-20 12:41:09 +02:00