pnpm lock file cataloger produces unstable output

[xnox]

What happened:

Run syft-json multiple times against the same lockfile. And yet it generates different output - flip-flopping artifact IDs.

          "foundBy" : "javascript-lock-cataloger",
-         "id" : "4e5335e9ddd15392",
+         "id" : "ecf707795b695f42",
          "language" : "javascript",
          "licenses" : [],
          "locations" : [
             {
                "accessPath" : "/pnpm-lock.yaml",
                "annotations" : {
                   "evidence" : "primary"
                },
                "path" : "/pnpm-lock.yaml"
             }
          ],
          "metadata" : {
             "dependencies" : {
-               "acorn" : "8.15.0"
+               "acorn" : "8.14.1"
             },
             "resolution" : {
                "integrity" : "sha512-rq9s+JNhf0IChjtDXxllJ7g41oZk5SlXtp0LHwyA5cejwn7vKmKp4pPri6YEePv2PU65sAsegbXtIinmDFDXgQ=="
             }
          },
          "metadataType" : "javascript-pnpm-lock-entry",
          "name" : "acorn-jsx",
          "purl" : "pkg:npm/acorn-jsx@5.3.2",
          "type" : "npm",
          "version" : "5.3.2"
       },

What you expected to happen:

The same syft json to be produced, all the time, producibly.

Steps to reproduce the issue:

1. git clone https://github.com/keycloak/keycloak -b 26.3.2
2. run: syft -o syft-json keycloak/js/pnpm-lock.yaml | sha256sum
3. observe unstable output

$ syft -o syft-json keycloak/js/pnpm-lock.yaml 2>/dev/null| sha256sum
5d3279d9189d4643fbb7f3f3aab7ad9ce2946a704c35813ba59f11b3bd590d84  -

$ syft -o syft-json keycloak/js/pnpm-lock.yaml 2>/dev/null| sha256sum
af2fab9c4fe4dd6423f2f49cc63f514737aec798dc35941aaa246206a77f048c  -

$ syft -o syft-json keycloak/js/pnpm-lock.yaml 2>/dev/null| sha256sum
af2fab9c4fe4dd6423f2f49cc63f514737aec798dc35941aaa246206a77f048c  -

$ syft -o syft-json keycloak/js/pnpm-lock.yaml 2>/dev/null| sha256sum
5d3279d9189d4643fbb7f3f3aab7ad9ce2946a704c35813ba59f11b3bd590d84  -

Anything else we need to know?:

The delta appears to be in metadata dependencies which might not be resolved deterministically.

Note similar flip flops are observed for other javascript packages too, for example babel dependencies.

Environment:

• Output of syft version:

$ syft version
Application: syft
Version: 1.42.1
BuildDate: 2026-02-18T17:42:49Z
GitCommit: 0a3f7bb
GitDescription: v1.42.1
Platform: linux/amd64
GoVersion: go1.25.7
Compiler: gc
SchemaVersion: 16.1.3

• OS (e.g: cat /etc/os-release or similar): Ubuntu

[xnox]

Oooh, I think this is because the lockfile is not deduplicated; and there are multiple deps and thus there are legitimate choices one can make.

But having stable and deterministic choices would be nice.

[xnox]

Hm even without duplicates, it can be unstable.

[kzantow]

Hey @xnox -- it looks like this is almost certainly due to directly iterating over maps in the pnpm cataloger, I see a number of instances of this, for example here and here. We should definitely make these sort the keys and iterate over any maps in a stable manner for consistent output. It seems I (or someone) wrote a generic function to sort into an iter.Seq2, if you felt like making this an upper-level internal utility and applying it to the pnpm cataloger where it iterates over maps, I think this should solve the issue of being nondeterministic.

[kzantow]

NOTE: we should write a ruleguard lint to prevent nondeterministic map iteration within catalogers. While this isn't required for this issue, it continues to cause headaches for nondeterministic behavior.