Overview

fossa analyze fails npm analysis on package-lock.json files that have no top-level dependencies key, with:

Error: parsing file: .../package-lock.json
  Error in $: key "dependencies" not found

npm legitimately omits the dependencies key when a project has zero dependencies (lockfileVersion 1 lockfiles for dependency-less packages are just {"name": ..., "version": ..., "lockfileVersion": 1}). Such a file also has no packages key, so detectNpmLockVersion routes it to the legacy (v1) parser, whose PkgLockJson FromJSON instance hard-required dependencies — failing the whole NpmProjectType analysis on a valid, npm-generated lockfile. This is the package-lock.json counterpart of the project.json fix in #1747.

This PR makes the key optional, defaulting to an empty map (exactly how the adjacent packages key is already handled), so a zero-dependency project analyzes successfully with an empty dependency graph.

Internal parser fix: no user-visible schema, CLI flag, or documented behavior change, so the docs/schema checklist items don't apply.

Acceptance criteria

Running fossa analyze on a project whose package-lock.json lacks a top-level dependencies key no longer fails with Error in $: key "dependencies" not found; the npm target analyzes successfully and reports no dependencies.

Testing plan

Added a regression test (test/Node/PackageLockSpec.hs) parsing a zero-dependency lockfile fixture (test/Node/testdata/no-dependencies-package-lock.json), which fails against the previous parser and passes with this change. Ran make fmt (fourmolu clean), hlint (no hints), and the Node-matched unit tests (86 examples, 0 failures).

To verify manually:

1. Build the CLI: make build-cli (or cabal build).
2. Create a directory containing a package.json ({"name": "empty-project", "version": "1.0.0"}) and a package-lock.json containing only {"name": "empty-project", "version": "1.0.0", "lockfileVersion": 1}.
3. Run fossa analyze --output in that directory. Before this change the npm target fails with Error in $: key "dependencies" not found; with this change analysis succeeds with an empty dependency graph.

Risks

A lockfile with neither dependencies nor packages that is malformed for some other reason now yields an empty graph instead of a fatal parse error. Since discovery only feeds real package-lock.json files here and an empty graph is the honest result for a lockfile that lists nothing, this seems strictly better than failing the analysis.

Metrics

This error pattern is visible on the fossa-cli-dashboard error patterns widget (14 occurrences of the package-lock.json variant in the 2026-08-20T22:54Z–2026-08-21T07:20Z scan window, ~279/week extrapolated).

References

• fossa-cli-dashboard error patterns widget
• [ANE-Bot] Fix project.json parse failure when dependencies key is absent #1747 (the analogous fix for NuGet project.json)

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

This PR description was generated with Claude Code

Generated by Claude Code