Hey everyone 👋
Has anyone else hit a real performance wall with the GitHub Advanced Security dependency graph in a monorepo? I'm working with a fairly large JavaScript/TypeScript monorepo (using pnpm workspaces), and the graph can take *forends* to update after a push. Sometimes it feels like it's analyzing the entire `node_modules` for every workspace from scratch.
I love the security insights, but the lag is making it hard to integrate into our fast-paced PR review cycle. By the time the alerts come in, the PR is often already merged!
From what I can piece together, it seems like the scanner might not be leveraging the monorepo's package manager structure efficiently. Here's what we're seeing:
* **Initial scan post-push:** Can take 20-30 minutes for a moderate change.
* **"No dependency information found"** messages on PRs for much longer than you'd expect.
* The slowness appears even when changes are isolated to a single package within the workspace.
I've tried tweaking the `.github/dependabot.yml` and making sure our `package.json` files are well-formed, but no major wins yet.
Has the community found any workarounds or config tips to speed this up? For instance:
* Is there a way to hint at the root directory for the workspace?
* Does using a `.gitignore` pattern to exclude nested `node_modules` help the scanner?
* Or is this just a current limitation we have to wait for GitHub to optimize?
Would love to hear your experiences and any clever hacks you've discovered.
-- Weave
Prompt engineering is the new debugging
You've hit on the main architectural weakness. The dependency graph scanner doesn't understand workspace hoisting or symlinks; it's performing a brute-force file system walk. Your suspicion it's analyzing every `node_modules` from scratch is likely correct for pnpm, because its symlinked structure doesn't play well with GitHub's generic detection logic.
One workaround we've forced is to break the monorepo into separate, smaller repositories for CI/CD and then use a build artifact to reassemble. It's a nuclear option, but it got our scan times from 45 minutes down to under 5.
Have you checked if you're inadvertently committing a massive `node_modules` or lockfile from a root install? That's a common tripwire that makes it scan everything.
FinOps first, hype last
Yeah, that 20-30 minute wait for a single package change rings a bell. While user1320's point about the scanner's brute-force approach is spot on, you might want to check a more subtle culprit first: the sheer number of manifest files.
The scanner often triggers a full re-scan if *any* `package.json` or lockfile in the monorepo changes hash, even if it's unrelated to your actual code change. A common trigger in pnpm workspaces is the root `pnpm-lock.yaml` getting a timestamp update from a concurrent install in another branch, which then forces a full graph rebuild for your PR.
Have you verified whether your lockfile is truly stable between the PR branch and main? That's usually a quicker check than a repo split.
Keep it civil, keep it real
That's a solid diagnostic step you've outlined. A stable lockfile is critical, but I've seen it break down in two specific monorepo scenarios that can still force a full rescan.
First, if you're using path aliases or file references (`"package-x": "file:../packages/package-x"`) in your workspace package.json files, the scanner sometimes interprets those as changed external dependencies on every run. Second, check your `.gitignore`. If `node_modules` isn't consistently ignored across all workspace roots, even a single stray folder can trigger the deep file walk.
You might also look at the GitHub Action logs for the dependency graph job. The initial lines often show the detected change set. If it lists hundreds of manifest files for a trivial PR, that's your confirmation the scanner isn't respecting workspace boundaries.