Dependabot alerts don't read bun.lock, so transitive…
0 reactions
Dependabot alerts don't read bun.lock, so transitive dependencies in Bun projects never get an alert
I noticed something odd on our Bun projects: every Dependabot alert was about a direct dependency. Never a transitive one.
It turns out GitHub's dependency graph doesn't read `bun.lock` yet. It supports `package-lock.json`, `yarn.lock` and `pnpm-lock.yaml`, but for Bun it falls back to `package.json`. So:
* Transitive dependencies aren't in the graph at all, so they never get an alert.
* Dependencies declared with `catalog:` are recorded with the literal version `catalog:`, which never matches an advisory.
In a minimal repro (`zod`, a package that pins an old `uuid`, and `happy-dom` through a catalog), `bun audit` finds 3 advisories and Dependabot raises 1.
Dependabot *version updates* do support Bun. This is only about alerts, which is what makes it easy to miss. And if you migrated from npm or Yarn, the alerts tied to your old lockfile get marked as fixed, even though the vulnerable packages are still in `bun.lock`.
**Are you affected?** Open Insights → Dependency graph. If your Bun projects only list `package.json` files, yes. Comparing your open alerts with `bun audit` makes it obvious.
**Fix:** until GitHub reads `bun.lock` itself, you can submit it through the dependency submission API. I made a GitHub Action for that: https://github.com/charpeni/bun-lock-submission
Full write-up, with a toggle that shows what GitHub reads versus what Bun installs: https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock
#technology #programming #js #dev
I noticed something odd on our Bun projects: every Dependabot alert was about a direct dependency. Never a transitive one.
It turns out GitHub's dependency graph doesn't read `bun.lock` yet. It supports `package-lock.json`, `yarn.lock` and `pnpm-lock.yaml`, but for Bun it falls back to `package.json`. So:
* Transitive dependencies aren't in the graph at all, so they never get an alert.
* Dependencies declared with `catalog:` are recorded with the literal version `catalog:`, which never matches an advisory.
In a minimal repro (`zod`, a package that pins an old `uuid`, and `happy-dom` through a catalog), `bun audit` finds 3 advisories and Dependabot raises 1.
Dependabot *version updates* do support Bun. This is only about alerts, which is what makes it easy to miss. And if you migrated from npm or Yarn, the alerts tied to your old lockfile get marked as fixed, even though the vulnerable packages are still in `bun.lock`.
**Are you affected?** Open Insights → Dependency graph. If your Bun projects only list `package.json` files, yes. Comparing your open alerts with `bun audit` makes it obvious.
**Fix:** until GitHub reads `bun.lock` itself, you can submit it through the dependency submission API. I made a GitHub Action for that: https://github.com/charpeni/bun-lock-submission
Full write-up, with a toggle that shows what GitHub reads versus what Bun installs: https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock
#technology #programming #js #dev
| 4,000 mlx | |
| 7 | |
| 0 |