fix: use correct projectName in container monitor JSON output
Summary
The projectName field in the JSON output of snyk container monitor --json contains the monitor's public ID (UUID) instead of the actual project name.
Changes
File: src/lib/ecosystems/monitor.ts
Changed line 214 from:
projectName: monitorResult.id,
to:
projectName: monitorResult.projectName,
Root Cause
The registry correctly returns projectName: project.name in the MonitorDependenciesResponse, but the CLI was overwriting it with monitorResult.id when building the JSON output.
Breaking Change Consideration
This is changing the JSON response of a CLI command, so it should be assessed for breaking change. I do NOT think it qualifies as a breaking change. The return type (string) and field key remain the same. The previous field value returned something completely unusable by the user (the monitor's public ID), as there is no public API call that references the monitor ID. This corrects a bug and should NOT negatively impact customer's existing use of the monitor command.
Steps to Reproduce (before fix)
snyk container monitor --json alpine:latest | jq '.projectName, .scanResult.name'
Output before fix:
"bcc57aaa-4415-4806-b2a4-4dd088f2c53b" # projectName (wrong - this is monitor.publicId)
null # scanResult.name
Expected output after fix:
projectName should contain the project's display name (e.g., automatically determined value from the image name or the value passed via --project-name).
| Warnings | |
|---|---|
| :warning: | There are multiple commits on your branch, please squash them locally before merging! |
Generated by :no_entry_sign: dangerJS against e90bdcb9ff8043bd2c3464fc726c3878044a98a6
@bgardiner I personally agree to your framing of this not being a breaking change but there is also a possibility that not all users agree.
So I think we want to be more explicit in the commit message/PR so that the release notes will clearly mention this behaviour. For example something like
fix(container): Replace project id by project name
Then I wonder if we can offer an alternative path for users who actually use the project id, for example in automations.