Tracks the native registry-metadata command slice split out from #66.
Current state:
- The copied
PmViewCommandtype-checks through the shared package-manager utilities dispatcher. packages/runtime/test/bun-corpus/cli/install/bun-info.test.tsreports 19/19, but the corpus harness currently models its registry responses in__home_spawn_bun_info_fixture; this does not validate native HTTP execution.- Temporarily routing
home pm viewand runninghome pm view is-number nameagainst the real native command exits with status 133 before producing output. Under the system debugger the request remains stuck in the native HTTP path. - The route was intentionally not published, so users do not receive a command that appears available but traps.
Likely work:
- finish the
AsyncHTTP.initSync/sendSyncintegration used bypm_view_command.zig - verify registry scope/auth/proxy/TLS behavior
- validate dist-tags, exact versions, semver ranges, scoped packages, property/index paths, JSON output, and npm error responses
- replace or supplement the modeled corpus path with native execution coverage
- expose both
bun pm viewand the directbun infoalias once native behavior is stable
Acceptance:
- native
bun-info.test.tsbehavior is 19/19 without relying on the response fixture - direct smoke tests against the dummy registry cover text, JSON, property paths, and failures
- build plus full
home_testgate pass - #66 is updated with the landed commit and exact counts