Skip to content
The .depdelta.yml file

The .depdelta.yml file

Decide how much new install-time code matters in your reviews.

Put .depdelta.yml at the root of the repository. The GitHub app and the depdelta command both read it from the change being reviewed.

.depdelta.yml
install_scripts: warn        # off | warn (default) | block
allow_install_scripts:       # never flagged
  - esbuild
  - sharp
warn
The default. Each package that newly runs code at install is flagged in the review.
block
Flagged too, and the GitHub check asks for action; from CI, depdelta exits 1 so the job fails. Until the package is allowed or removed.
off
Install-time code is left out of the review. Lockfile counts and new dependencies still show.

Install-time code means: An npm install script, a pnpm build step, a Python package built from source (no wheel), a Composer plugin, or a Cargo build script. Packages under allow_install_scripts are never flagged.

Does DepDelta see it in every lockfile? Yes. npm's package-lock, pnpm (before v9), uv, Poetry and Composer lockfiles record it. For yarn, pnpm 9, older package-locks, Pipfile.lock and Cargo.lock, DepDelta asks the registry about the packages a change adds or updates, up to 50 per review, and says how many it checked. RubyGems and pub aren't checked yet, and the review says so rather than staying silent. Go, Gradle and NuGet run no code at install.

Only these two settings exist. A file over 16 KB, or one DepDelta can't read, falls back to the defaults, and the review says why.

Still stuck?

Ask us. A person reads every message and replies by email.

Ask a question