fix: use correct projectName in container monitor JSON output

[bgardiner]

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).

[adrobuta]

changes look good. I have only one question, do you think having the a non unique project name reported for base image/ application project could break any automation around the json output?
Current behavior: json output for node:lates
cat json_output | jq '.[].projectName' "bae0b739-9d1c-4e04-99ac-3e7af3faa271" "73e39537-0bf5-45ed-9621-06d83dc9d69f"

the projectName will be same for both projects

[bgardiner]

It should not actually be the same projectName for both projects. One will have a target file appended. For example, when setting --project-name=brians_project on a container with a JS application, there are two different projects created:

• brians_project:/usr/lib/node_modules (JS app)
• brians_project (base image)

[github-actions]

	Warnings
⚠️	There are multiple commits on your branch, please squash them locally before merging!

Generated by 🚫 dangerJS against e90bdcb

[PeterSchafer]

@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.

Thinking about the breaking change nature of this I dismissed my approval to have a bit more of a conversation.