package-upgrade

Start with pnpm audit to prioritize vulnerable packages, then run pnpm update for targeted packages rather than updating everything. Always review the lockfile diff with git diff pnpm-lock.yaml for unexpected transitive dependencies or new build scripts before committing.

First try upgrading the direct dependency that pulls it in, then check whether upstream has a fix in progress. If neither works and the attack surface is real, add a pnpm.overrides entry with documented removal conditions; otherwise record it as an accepted risk.

minimumReleaseAge enforces a cooldown so pnpm only resolves package versions published more than a set time ago, preventing freshly published malicious versions from being installed. Avoid adding minimumReleaseAgeExclude entries except for urgent hotfixes.

strictDepBuilds fails the install when a dependency outside the allowBuilds list contains a build script, blocking malicious postinstall code. Investigate what the script does before adding the package to the allowlist rather than silencing the error.

Check on every dependency update whether the parent dependency now pulls a fixed version of the overridden package using pnpm why and pnpm outdated. If upstream has fixed the issue, delete the override, run pnpm install, and verify audit and tests pass.

A changeset with a version bump is required when the update changes runtime artifacts, such as security fixes to shipped libraries. Updates limited to devDependencies or CI tooling can use an empty changeset or none, depending on the repository's CI requirements.