Levandor

depcheck false positive on a huge minified bundle (CI-only)

2 min read

vuer_css CI reported @emotion/is-prop-valid as an unused dependency while the exact same pinned depcheck@1.4.7 on the same lockfile reported clean locally and inside a Linux container. Cause: the only reference to the package lives in an 865 KB minified vendor bundle that depcheck’s parser fails on in CI (OOM/timeout on the self-hosted runner), after which the file is treated as containing no requires at all.

Do NOT "fix" this by removing the dependency

The dependency is genuinely used. Remove it and depcheck flips from reporting it unused to reporting it missing — the same job goes red from the other direction. Suppress it in .depcheckrc.json instead.

Symptoms

  • CI job Unused Dependencies lists @emotion/is-prop-valid.
  • npx -y depcheck@1.4.7 locally (macOS) → clean.
  • Same command in a Linux container with the same yarn.lock → clean.
  • No difference in depcheck version, config, or dependency tree.

Root cause

vuer_css/web/sdk/web-sdk.js:205 contains a literal, wrapped-in-try/catch reference:

require("@emotion/is-prop-valid")

web/sdk is not in .depcheckrc.json’s ignore-patterns, so depcheck does try to parse the file. Locally it parses it, sees the require, and marks the package used. On the self-hosted CI runner the 865 KB minified bundle evidently fails to parse (memory/time), and depcheck’s failure mode is to treat an unparseable file as containing no requires — silently. Hence a machine-dependent false positive.

For Agents

Generalized rule: a depcheck result that differs between CI and local, with identical tool version + lockfile, points at a file depcheck could not parse, not at a real dependency change. Look for large minified/vendored bundles that are inside the scan surface. depcheck fails open (file → no requires), so parse failures always surface as “unused”, never as an error.

Fix applied

Added the package to ignores in vuer_css/.depcheckrc.json — the same suppression mechanism FKITDEV-8239 set up for dynamically-loaded runtime deps. (Adding web/sdk to ignore-patterns would also work but would blind the scan to the rest of the bundle.)

The job is continue-on-error: true and not in any needs: graph, so this never blocked the PR — but a red-looking check invites exactly the wrong “fix” from the next person.

Graph View

Backlinks