agent pinned a git SHA for a hotfix and never converted it back to a version range - the dep is frozen at a...
Fixes dependencies frozen at ancient git SHAs because an agent pinned a commit for a hotfix and never converted it back to a version range. Use when upgrade automation ignores a dependency or a manifest contains a raw commit hash. Key trigger: a 40-char hex SHA in the manifest or lockfile source.
TL;DR: Convert the SHA pin back to a version range now, and put an expiry date on every emergency pin when it is created. A SHA pin bypasses all future upgrade automation - no tool proposes bumps for a commit hash. Check whether the old commit is behind on security fixes first, then bump deliberately.
agent pinned a git SHA for a hotfix and never converted it back to a version range - the dep is frozen at a two-year-old commit- Find the pin: search manifests and lockfiles for raw commit SHAs or git URLs with hashes. Expected: locates the frozen dependency and the pinned commit.
- Check what you missed: compare the pinned commit's date against the package's releases since then. Expected: a list of missed versions, including any security releases.
- Audit the missed range for CVEs before you touch anything. Expected: you know whether the frozen dependency is vulnerable, which sets the urgency.
- Replace the SHA with a version range at a current release, reinstall, and run the tests. Expected: the manifest shows a range and the lockfile resolves to a real published version.
- Set policy: emergency pins get a dated TODO plus a tracking issue, and a scheduled check flags pins older than N days. Expected: no pin survives past its expiry unnoticed.
Use this when
- A dependency is pinned to a git SHA long after the hotfix
- Upgrade automation silently ignores a dependency
- You need pin-expiry policy for emergency pins
- A manifest contains a raw commit hash with no expiry note
Not for this skill when
- The pin is intentional and reviewed, like a vendored fork
- SHAs are the permanent install method for an unreleased package - then document that choice
- The hotfix pin is still within its planned window
Variant phrasings
- Dependency frozen at old git commit
- SHA pin never converted to version
- Hotfix pin still pinned two years later
- Commit-hash dependency ignored by upgrades
Why it happens
The pin was the fastest path during the incident, and nothing in the system remembers it was meant to be temporary. Version ranges are what upgrade tools understand - a commit SHA is opaque to them, so the dependency silently drops out of every future upgrade cycle while the world moves on around it.
Edge cases
- The hotfix may never have been released upstream - then the pin needs a fork or a patch workflow, not just a range swap
- Converting to a range can jump multiple majors at once - treat it as a fresh upgrade with full verification
- Lockfiles record the resolved SHA even for range installs - that is fine, the range is what keeps automation working
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_mvaPu7ZdWMHKB12ipg7J-g