JS-1717 Cache parsed dependency manifests and preload pnpm-workspace.yaml

[guillemsarda]

Part of JS-733 epic

[hashicorp-vault-sonar-prod]

JS-1717

[sonar-review-alpha]

Summary

This PR adds parsing-level caching for dependency manifests (package.json, deno.json, deno.jsonc, pnpm-workspace.yaml) to avoid redundant parsing operations during analysis.

Key changes:

• New parsed-dependency-files.ts centralizes manifest parsing logic with three separate caches (one per manifest type), using a generic caching pattern to avoid repeated parse calls
• Refactors DependencyManifestStore from separate typed maps for each manifest kind into a unified manifestsByName structure, reducing code duplication and making the manifest handling more uniform
• Elevates pnpm-workspace.yaml to "preloadable" status alongside existing manifests, enabling index-based lookups and workspace catalog resolution
• Consolidates previously scattered parsing functions (from npm.ts, deno.ts, dependencies.ts) into the new cache module
• Tests verify caching is effective: JSON/YAML parsing is called during warmup but not on subsequent manifest accesses, even on repeated calls

What reviewers should know

What to focus on:

1. Cache validity and invalidation — Verify clearParsedDependencyFileCache() is called at appropriate times. The test at line ~115 confirms cache entries persist correctly across multiple rule invocations after warmup.

2. pnpm-workspace.yaml special cases — This file is now indexed like other manifests, but it has different behavior:

   • fillManifestCaches doesn't populate patternInParentsCache for it (index.ts lines 48–50) — verify this is intentional
   • clearDependenciesCache conditionally clears its cache (index.ts line 91) — check the logic is consistent

3. Generic manifest storage pattern — manifestsByName in DependencyManifestStore now treats all manifest types uniformly (lines 42–46 of dependency-manifests.ts). Ensure the iteration logic correctly handles the pnpm workspace file.

4. Parsing error caching — The test at line ~155 (deno-jsonc-malformed) verifies that parse failures are cached. Confirm this prevents spam of debug logs when the same malformed file is accessed repeatedly.

5. Type safety — The renamed types (PreloadableDependencyManifestName, isPreloadableDependencyManifestPath) now include pnpm-workspace.yaml. Check that all call sites that check manifest types use the updated function names.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
92.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[vdiez]

Review

Looks good to me. I checked this against JS-1717 and the PR covers the expected behavior:

• pnpm-workspace.yaml is now discovered and preloaded through the dependency manifest store path.
• Parsed npm, pnpm, and Deno manifests are cached on demand.
• Failed parses are cached as well.
• Dependency cache invalidation also clears the parsed-manifest caches.

Validation run:

• Focused dependency-manifest tests passed.
• Focused tsconfig tests passed.

Future Improvement

Non-blocking cleanup idea: this PR already moves pnpm-workspace.yaml into upfront file-store discovery, which is the right direction. As a follow-up, we may want to make the terminology and ownership more explicit by separating discoverable dependency files from standalone dependency manifests.

The file store probably should not care about the semantic difference between pnpm-workspace.yaml and files like package.json, deno.json, or deno.jsonc. From the store perspective, they are all dependency-related files worth discovering, reading, and preloading into lookup caches. The distinction that package.json / Deno files produce manifests while pnpm-workspace.yaml is supporting metadata for npm resolution should live only in the dependency resolvers.

That would also improve readability by unifying how we handle discovery and lookup-cache preloading for all dependency-related files. For example, the shared discovery/preload layer could expose all discoverable dependency files uniformly, while resolver-specific code decides whether a file contributes a standalone manifest, enriches another manifest, or needs a parent-list lookup cache. The current implementation works, but making that split explicit could make future package-manager support easier to reason about.