Reddit Programming

dashboard to display component details instantly. Step 3: Parse Lock Files (The Hard Part) This was the gnarly part. Four different formats, each with quirks. Yarn Lock (v1 Classic) Looks like TOML with nested dependency lists: Code "@pkgjs/parseargs@^0.11.0": version "0.11.0" resolved "https://registry.npmjs.org/..." dependencies: package-json "^6.0.0" I wrote a line-by-line parser. The trick: track indentation to know when you're inside a package block vs. dependency list. npm package-lock.json Flat JSON structure (v2/v3): JSON { "packages": { "node_modules/lodash": { "version": "4.17.21", "dependencies": { ... } } } } Easier to parse with JsonDocument, but the key names have node_modules/ prefixes that need stripping. pnpm-lock.yaml YAML with name@version keys: YAML packages: /lodash/4.17.21: version: 4.17.21 dependencies: react: 18.2.0 I treated this as mostly line-based text parsing since I didn't want to add a full YAML dependency. Works for the common cases. Bun Lock JSONC format with array-based entries. Least common, so I parse it but mark binary bun.lockb files as unparseable. Step 4: Resolve Dependencies Once I had a parsed lock file, I needed to extract: Local dependencies (internal workspace packages like u/company/shared) Direct dependencies (what's explicitly in package.json) Transitive dependencies (what your dependencies need) C# // Read package.json dependencies var directRanges = ReadDirectDependencyRanges(packageJsonContent); // For each direct dep, look it up in the lock file foreach (var (name, range) in directRanges) { var pkg = Resolve(name, range, parsedLock); if (pkg != null) { // It's resolved to version X.Y.Z direct.Add(new ResolvedDependency(pkg.Name, pkg.Version, range)); // Queue it to traverse its dependencies queue.Enqueue(pkg); } } // Depth-first traversal to collect transitives while (queue.TryDequeue(out var pkg)) { foreach (var (depName, depRange) in pkg.DependencyRanges) { var dep = Resolve(depName, depRange, parsedLock); if (dep != null && !visited.Contains($"{dep.Name}@{dep.Version}")) { transitive.Add(...); queue.Enqueue(dep); } } } Result: Three lists of ResolvedDependency objects with exact versions and requested ranges. Silverfish uses this to build the full dependency graph in its UI. Step 5: Handle Monorepos Monorepos have multiple package.json files. The key insight: walk up the directory tree to find the root lock file. C# static IEnumerable AncestorDirs(string dir) { var current = dir; while (true) { yield return current; if (string.IsNullOrEmpty(current)) break; current = Path.GetDirectoryName(current); } } So packages/web/package.json in an entria-style monorepo correctly finds the root yarn.lock instead of failing. Each workspace member gets its own component record in Silverfish. How the Silverfish IDP Uses This Once the analyzer extracts all this metadata, it: Maps dependencies visually — showing which components depend on what Flags version mismatches — when different packages pin different versions of the same library Detects tech stacks — knowing which services are frontend, which are backend, which databases they use Tracks upgrades — identifying outdated packages and planning coordinated updates Enables governance — enforcing policies like "no direct jquery dependencies" or "all frontends must use React 18+" Lessons Learned Abstraction beats assumptions: I wrote the whole thing to accept Func> readFileContentAsync instead of directly reading files. This made it testable and backend-agnostic (GitHub API, filesystem, cache, whatever). Format-specific parsing is worth it: I could have given up on Yarn/pnpm/Bun and only parsed npm lock files. But each format's parser is ~100-150 lines and handles real repos that exist in the wild. Conflicts are data, not errors: Instead of failing when I find multiple lock files, I report them. That's valuable information ("why do you have both yarn.lock and package-lock.json?"). Monorepos are normal: Walking ancestor directories

2 views02:33