Summary
The dependency-audit job in reusable-governance-gates.yml runs npm audit --audit-level=high without --omit=dev. For Cloudflare Worker repositories — where wrangler is a devDependency and never ships to the Worker runtime — this produces false failures from wrangler's transitive dev tree (undici, esbuild, miniflare, vite, rollup, picomatch, defu).
The production bundle that actually runs on Cloudflare is unaffected. Only the local dev toolchain is.
Reproduction (observed in chittydispute CHITTYOS/chittydispute#13)
# package.json runtime deps: only @neondatabase/serverless
# package.json devDependencies: wrangler, @cloudflare/workers-types, typescript, vitest
npm audit --audit-level=high
# → 8 vulnerabilities (3 moderate, 5 high)
# → all in wrangler's transitive tree
npm audit --audit-level=high --omit=dev
# → found 0 vulnerabilities
The vulnerable packages (undici <=6.23.0, esbuild <=0.24.2, etc.) exist on the build machine and in node_modules/ during local wrangler dev, but they are not part of the worker bundle deployed to Cloudflare. For Workers, dev-only audit failures are noise.
Current workaround in chittydispute (CHITTYOS/chittydispute#14)
Added package.json overrides:
"overrides": {
"undici": "^6.23.1",
"esbuild": "^0.25.0"
}
Combined with npm audit fix for the non-breaking upgrades (defu, picomatch, rollup, vite). This gets to 0 vulnerabilities without the wrangler 3→4 breaking upgrade. But it's a local fix in every Worker repo — the canon-level solution is better.
Proposed fixes
Option A — Add a workflow_call input
on:
workflow_call:
inputs:
audit_omit_dev:
required: false
type: boolean
default: false
And in the job:
- name: Dependency Audit (High+)
if: ${{ steps.lockfile.outputs.present == 'true' }}
run: npm audit --audit-level=high ${{ inputs.audit_omit_dev && '--omit=dev' || '' }}
Cloudflare Worker repos opt in via:
jobs:
gates:
uses: ./.github/workflows/reusable-governance-gates.yml
with:
audit_omit_dev: true
secrets: inherit
Pros: explicit, backward-compat, easy to reason about.
Cons: requires each Worker repo to opt in.
Option B — Auto-detect Worker repos
Check for presence of wrangler.jsonc or wrangler.toml and auto-apply --omit=dev:
- name: Dependency Audit (High+)
run: |
if [[ -f wrangler.jsonc || -f wrangler.toml ]]; then
npm audit --audit-level=high --omit=dev
else
npm audit --audit-level=high
fi
Pros: zero-config for adopters.
Cons: implicit behavior; may surprise maintainers; assumes wrangler is always a devDep.
Option C — Do nothing, document the overrides workaround
Update the baseline docs to show Worker repos how to add package.json overrides. No workflow change.
Pros: no canon change.
Cons: every Worker repo reinvents the workaround.
Recommendation: Option A — explicit input is the canonically cleanest. Document Option C in the baseline README as the fallback for non-dev-audit scenarios.
Related
Summary
The
dependency-auditjob inreusable-governance-gates.ymlrunsnpm audit --audit-level=highwithout--omit=dev. For Cloudflare Worker repositories — wherewrangleris adevDependencyand never ships to the Worker runtime — this produces false failures from wrangler's transitive dev tree (undici, esbuild, miniflare, vite, rollup, picomatch, defu).The production bundle that actually runs on Cloudflare is unaffected. Only the local dev toolchain is.
Reproduction (observed in chittydispute CHITTYOS/chittydispute#13)
The vulnerable packages (undici <=6.23.0, esbuild <=0.24.2, etc.) exist on the build machine and in
node_modules/during localwrangler dev, but they are not part of the worker bundle deployed to Cloudflare. For Workers, dev-only audit failures are noise.Current workaround in chittydispute (CHITTYOS/chittydispute#14)
Added
package.jsonoverrides:Combined with
npm audit fixfor the non-breaking upgrades (defu, picomatch, rollup, vite). This gets to 0 vulnerabilities without the wrangler 3→4 breaking upgrade. But it's a local fix in every Worker repo — the canon-level solution is better.Proposed fixes
Option A — Add a workflow_call input
And in the job:
Cloudflare Worker repos opt in via:
Pros: explicit, backward-compat, easy to reason about.
Cons: requires each Worker repo to opt in.
Option B — Auto-detect Worker repos
Check for presence of
wrangler.jsoncorwrangler.tomland auto-apply--omit=dev:Pros: zero-config for adopters.
Cons: implicit behavior; may surprise maintainers; assumes wrangler is always a devDep.
Option C — Do nothing, document the
overridesworkaroundUpdate the baseline docs to show Worker repos how to add
package.jsonoverrides. No workflow change.Pros: no canon change.
Cons: every Worker repo reinvents the workaround.
Recommendation: Option A — explicit input is the canonically cleanest. Document Option C in the baseline README as the fallback for non-dev-audit scenarios.
Related