Description

view.handler prints bin names from Object.keys(info.bin) without applying pnpm’s bin-name
normalization and validation, so it may display bin names that would not actually be linked/usable
(e.g. scoped keys or otherwise-invalid names). This makes the new bin: output potentially
incorrect for some package manifests.

Code

deps/inspection/commands/src/view/index.ts[R137-149]

+  if (info.bin) {
+    let bins: string[] = []
+    if (typeof info.bin === 'string') {
+      if (info.bin.length > 0 && info.name) {
+        bins = [info.name[0] === '@' ? info.name.slice(info.name.indexOf('/') + 1) : info.name]
+      }
+    } else {
+      bins = Object.keys(info.bin)
+    }
+    if (bins.length > 0) {
+      lines.push('')
+      lines.push(`bin: ${chalk.cyan(bins.join(', '))}`)
+    }

Evidence

The new view implementation prints raw bin object keys, while pnpm’s bin resolver normalizes
scoped names and filters invalid names before treating them as bins; therefore view can disagree
with actual linked bin names.

deps/inspection/commands/src/view/index.ts[137-149]
bins/resolver/src/index.ts[63-78]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm view` now renders a `bin:` line, but it builds the list from raw manifest keys (`Object.keys(info.bin)`). pnpm’s bin-linking logic applies normalization (e.g. scope-stripping) and filters invalid/unsafe bin names; as a result, `pnpm view` can show bin names that won’t exist after installation.
### Issue Context
The `bin` section in `deps/inspection/commands/src/view/index.ts` should reflect the same bin names that pnpm would actually expose.
### Fix Focus Areas
- deps/inspection/commands/src/view/index.ts[137-149]
- bins/resolver/src/index.ts[63-78]
### Suggested fix
- When `info.bin` is an object, derive displayed bin names by applying the same normalization rules used by pnpm bin resolution:
- Strip scope from any bin key that starts with `@` (use the segment after the `/`).
- Filter out invalid names (empty, `.`, `..`, and names that fail the same URL-safe validation pnpm uses).
- Consider extracting/reusing a shared helper for “normalize bin name(s) for display/linking” so `view` stays consistent with the bin linker over time.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

view.handler prints a bin: line for any truthy info.bin, so an empty bin object renders as
bin: with no entries. pnpm elsewhere treats an empty bin map as “no bin”, so this output is
misleading.

Code

deps/inspection/commands/src/view/index.ts[R137-141]

+  if (info.bin) {
+    const bins = typeof info.bin === 'string' ? [info.bin] : Object.keys(info.bin)
+    lines.push('')
+    lines.push(`bin: ${chalk.cyan(bins.join(', '))}`)
+  }

Evidence

The new view rendering uses Object.keys(info.bin) and prints regardless of key count, so {}
becomes an empty bin: line. pnpm’s dependency resolver logic explicitly checks for
Object.keys(pkg.bin).length === 0 to treat it as no-bin, demonstrating the intended semantics for
empty bin maps.

deps/inspection/commands/src/view/index.ts[127-141]
installing/deps-resolver/src/resolveDependencies.ts[1607-1610]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`view.handler` currently renders a `bin:` line whenever `info.bin` is truthy. If `info.bin` is an empty object (`{}`), this produces `bin: ` (empty list), which is misleading.
## Issue Context
Other pnpm codepaths explicitly treat `bin: {}` as equivalent to “no bins”, so `view` should not print a `bin:` line unless at least one bin name exists.
## Fix Focus Areas
- deps/inspection/commands/src/view/index.ts[137-141]
## Suggested change
- Compute `bins` as today.
- Only push the blank line + `bin:` line if `bins.length > 0`.
- Optionally, treat an object bin with `Object.keys(info.bin).length === 0` as absent (same effect).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

view.handler prints a string-valued bin as the raw relative path (e.g. cli.js) instead of the
executable name derived from the package name (scope-stripped), so reported bins are wrong for
shorthand bin manifests.

Code

deps/inspection/commands/src/view/index.ts[R137-141]

+  if (info.bin) {
+    const bins = typeof info.bin === 'string' ? [info.bin] : Object.keys(info.bin)
+    lines.push('')
+    lines.push(`bin: ${chalk.cyan(bins.join(', '))}`)
+  }

Evidence

The current implementation uses the raw string bin value, but pnpm types and existing bin
resolution show that string bin is a path and executable name should be derived from the package
name (scope removed).

deps/inspection/commands/src/view/index.ts[137-141]
core/types/src/package.ts[5-6]
core/types/src/package.ts[90-98]
bins/resolver/src/index.ts[63-68]
pnpr/.fixtures/packages/@foo/touch-file-one-bin/1.0.0/package.json[1-5]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `view` command prints `bin` values incorrectly when `info.bin` is a string. In package manifests, a string `bin` value represents the executable *path*, while the executable *name* should be derived from the package name (and for scoped packages, the scope must be stripped).
### Issue Context
- `PackageBin` is defined as `string | { [commandName: string]: string }`, where the string form is a path.
- pnpm’s own bin resolution logic derives the command name from the package name and strips scope.
### Fix Focus Areas
- deps/inspection/commands/src/view/index.ts[137-141]
### Suggested fix
Replace the current `bins` computation with logic that mirrors pnpm bin naming:
- If `info.bin` is a string: use `info.name` as the command name, but strip scope (`@scope/name` -> `name`).
- If `info.bin` is an object: use its keys, but also strip scope for any key starting with `@`.
Example helper:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Walkthrough

The view command now displays deprecation notices and improves bin field handling. When a package has deprecation metadata, a "DEPRECATED!" section is appended. The bin field is normalized from string or object and rendered as a comma-separated bin: line. Tests and a changeset were added.

Changes

View Command Deprecation and Bin Display

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• zkochan

Poem

🐰 A tiny note that time has passed,
"DEPRECATED!" now appears at last.
Bins lined up in tidy rows,
The view command politely shows.
Hoppity hops — the rabbit knows!

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn