97 Dependabot alerts arrived at once and nothing separates the five that ship to users from the ninety that do not

[50rayn]

Enabling Dependabot alerts (#385) surfaced 97 open alerts at once — 3 critical, 54 high, 38 medium, 2 low — across 22 distinct packages. All but three report manifest_path: pnpm-lock.yaml, so GitHub's own grouping says nothing about which ones matter.

A list of 97 with no ordering is functionally the same as no list. This is the pass that turns it into a small number of real items and a large number of knowingly-accepted ones.

The 22 packages

@sveltejs/kit  axios  basic-ftp  brace-expansion  cookie  esbuild  extract-zip
flatted  follow-redirects  form-data  immutable  ip-address  js-cookie  js-yaml
lodash  minimatch  picomatch  postcss  shell-quote  svelte  tar  vite

A first pass, to be checked rather than trusted

I walked pnpm list --prod --depth Infinity --filter "./packages/**" and intersected it with the alert list. Three groups came out, and the distinction that matters is prod dependency vs peer dependency — Dependabot cannot see it, and it decides who is responsible for the fix.

Group A — genuinely ours. Real dependencies of a published package, so the version is ours to bump and it lands in a consumer's node_modules:

package	path
basic-ftp (critical)	@poveste/plugin-percy > @percy/sdk-utils > pac-proxy-agent > get-uri
extract-zip (high)	@poveste/plugin-percy > puppeteer > @puppeteer/browsers
ip-address (high)	@poveste/plugin-percy > @percy/sdk-utils > … > socks
shell-quote (critical)	@poveste/plugin-vue > launch-editor
js-yaml (high)	poveste > gray-matter

Group B — the consumer's, via a peer. These resolve in our lockfile but reach a user through a package they install at their version. @sveltejs/kit, svelte and cookie arrive as peerDependencies of @poveste/plugin-svelte; brace-expansion, flatted, lodash, minimatch and tar all arrive under nuxt, a peer of @poveste/plugin-nuxt. Bumping our lockfile changes nothing for them. If anything is owed here it is a peer range, not a patch.

Group C — dev-only. axios, follow-redirects, form-data, js-cookie never appear in a production tree. Real work to keep current, zero exposure for anyone installing poveste.

esbuild, postcss, picomatch, immutable and vite need a closer look than I gave them — every chain I found runs through vite, which is a peer of poveste but also a real dependency of vite-node. That ambiguity is exactly the kind this pass exists to resolve, and I would rather flag it than guess.

The finding worth acting on regardless

@poveste/plugin-percy declares puppeteer and @percy/sdk-utils as runtime dependencies. Those two alone account for all three Group A alerts that are not ours by choice — including the only critical outside shell-quote — and they drag a browser download stack (basic-ftp, extract-zip, ip-address, a proxy chain) into the install of anyone adding Percy support.

That is worth a question separate from the advisories: does a poveste Percy plugin need to bundle a browser, or is puppeteer a peer the way nuxt and svelte already are? If it becomes a peer, three alerts stop being ours permanently rather than until the next advisory.

What done looks like

• Every one of the 97 sorted into A, B or C, with the resolution path recorded — the path is the evidence, the severity is not
• Group A fixed or accepted with a reason, one at a time
• Group B and C dismissed in the GitHub UI with the standard reason, so the open count reflects real exposure and the list stays readable
• The prod-vs-peer method written down somewhere durable, because this recurs on every advisory and re-deriving it is the expensive part

Explicitly not the goal

Getting the number to zero. Most of these are transitive dev-tooling advisories about DoS in a build step, and chasing them produces churn that trains everyone to ignore the same inbox the real ones land in. A small, current, honestly-triaged list beats an empty one.

Related: #385 (which turned this on), #453 and #452 (the grouped security PRs already opening on their own).