feat: verify and fix CVE Lite CLI compatibility with NX workspaces

[sonukapoor]

Summary

Verify and document CVE Lite CLI compatibility with NX workspaces, and fix any gaps found.

NX is a widely used monorepo build system for JavaScript and TypeScript projects. NX workspaces come in two forms:

Integrated repos - single root lockfile (package-lock.json, pnpm-lock.yaml, or yarn.lock) with all dependencies managed at the root. CVE Lite CLI likely works here already.

Package-based repos - each project under apps/ or libs/ has its own package.json and potentially its own lockfile. CVE Lite CLI's --search-depth flag may or may not discover these depending on the workspace structure.

What needs investigation

• Does cve-lite . --search-depth 4 correctly discover lockfiles nested inside NX apps/ and libs/ directories?
• Does CVE Lite CLI handle the case where there is a root lockfile AND nested lockfiles (mixed)?
• Does the output correctly label findings by workspace project?
• Does --search-depth need to be higher for deeply nested NX structures?

Acceptance criteria

• Run CVE Lite CLI against a real NX workspace (integrated and package-based)
• Document the recommended scan command for NX in the docs
• Fix any lockfile discovery gaps found during testing
• Add an NX example under examples/ if a gap is fixed

References

• NX integrated repos: https://nx.dev/concepts/integrated-vs-package-based
• NX package-based repos: https://nx.dev/concepts/integrated-vs-package-based

[Demiserular]

Hey @sonukapoor I looked in to the following problemns :

1. NX package-based repos have per-project lockfiles under apps/ and libs/ that may not be discovered
2. Mixed scenarios (root lockfile + nested lockfiles) only scan the root lockfile currently
3. Findings need to be labeled by workspace project with project-specific fix commands

I think we should :

1. Update multi-folder mode trigger to handle mixed scenarios (root + nested lockfiles)
2. Modify loadMultiplePackages() to include root lockfile when nested lockfiles exist
3. Ensure --search-depth 4 covers standard NX structures
4. Add NX documentation and example fixture for testing

after this it maintains backward compatibility while adding support for the previously missed mixed scenario.
I would love to help in case these solutions aligns with you.

[sonukapoor]

Hi @Demiserular, thanks for digging into this - solid analysis.

One thing worth knowing before you start: multi-folder scan already labels findings by workspace project and generates project-specific fix commands. So point 3 in your problem list may already be handled. Worth verifying.

The most useful first step would be to actually run CVE Lite CLI against a real NX workspace (both integrated and package-based) and document what you find. The --search-depth flag controls how deep the lockfile discovery goes, so cve-lite . --search-depth 4 --verbose is the right starting point for a package-based repo.

For the mixed scenario (root lockfile + nested lockfiles coexisting) - that's a trickier design question and we'll handle the code changes there ourselves. But if you want to contribute, the most valuable thing would be:

1. Test results from a real NX workspace with your findings documented
2. A recommended scan command for the docs
3. An NX example fixture under examples/ if you find a gap

That would give us everything we need to close the issue. Happy to review and merge that.

[Demiserular]

@sonukapoor I start working then

[sonukapoor]

Before you start writing any code - the most valuable first step is just testing. Set up or find a real NX workspace and run cve-lite . --search-depth 4 --verbose against it. Document what works and what doesn't.

The code changes (mixed scenario handling, multi-folder trigger updates) are not in scope for this contribution - we'll handle those ourselves once we have your test findings. What we're looking for from you is: test results, a recommended scan command for the docs, and an examples/ fixture if you confirm a gap exists.

[Demiserular]

Understood - I'll focus on testing and documentation only, leaving the code changes to you.
It think we can move like :

1. Test CVE Lite CLI against real NX workspaces (integrated and package-based) using cve-lite . --search-depth 4 --verbose
2. I'll Document what works and what doesn't
3. then i can provide a recommended scan command for the docs
4. only then we will add an NX example fixture under examples/ if I confirm a gap exists

I won't make any code changes to the mixed scenario handling or multi-folder trigger logic - that's your scope. Once I have the test findings, I'll share them so you can handle the design decisions and implementation.

[Demiserular]

I have completed the testing against various NX workspace structures and added the example fixtures for reproducing the behavior.

Here is the update you can post on the issue to reply to the maintainer:
@sonukapoor Here are my test findings and the requested documentation/fixtures:

Test Results

I tested CVE Lite CLI against three different NX workspace structures:

1. Integrated Workspace (examples/nx-integrated): Works perfectly out of the box. The CLI successfully discovers the root package-lock.json and scans the dependencies without needing any extra flags.
2. Package-based Workspace (Nested lockfiles only) (examples/nx-package-based): Works perfectly! By using the --search-depth 4 flag, the CLI correctly discovers the individual package-lock.json files inside apps/ and libs/, runs a multi-folder scan, and labels the findings accurately by folder.
3. Mixed Scenario (Root lockfile + Nested lockfiles) (examples/nx-mixed): GAP CONFIRMED. When a root package-lock.json is present alongside nested lockfiles, the CLI only parses the root lockfile and skips the nested lockfiles entirely, even when the --search-depth 4 flag is provided.

Recommended Scan Command for the Docs

For NX package-based workspaces, the recommended command to discover lockfiles within apps and libs is:

cve-lite . --search-depth 4

Let me know if you need any additional testing.