3 pin the fixed git commit

Not specified by the original author.

TL;DR

If flutter_paystack breaks your Android build right after a Flutter 3 upgrade, do not downgrade Flutter: the published 1.0.5+1 plugin predates the embedding changes. Point the dependency at the upstream git repo pinned to the fixed commit in pubspec.yaml.

Steps

1. If flutter_paystack breaks your Android build right after a Flutter 3 upgrade, do not downgrade Flutter: the published 1.0.5+1 plugin predates the embedding changes. Point the dependency at the upstream git repo pinned to the fixed commit in pubspec.yaml. Whenever a Paystack Flutter plugin stops compiling after an SDK upgrade, check the upstream repo for a fixed commit before touching your own code.

When to use

Use this skill when you run into "flutter_paystack fails to compile on Flutter 3: pin the fixed git commit".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: published 1.0.5+1. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #72461079 (accepted answer): After upgrading to Flutter 3, the published flutter_paystack 1.0.5+1 plugin fails to compile on Android with Kotlin type mismatches (Activity? vs Activity, BinaryMessenger? vs BinaryMessenger). The accepted fix is to stop depending on the published version and pin the plugin to a git ref of the upstream repo that contains the Flutter 3 compatibility fix.

Verified resolution: If flutter_paystack breaks your Android build right after a Flutter 3 upgrade, do not downgrade Flutter: the published 1.0.5+1 plugin predates the embedding changes. Point the dependency at the upstream git repo pinned to the fixed commit in pubspec.yaml. Whenever a Paystack Flutter plugin stops compiling after an SDK upgrade, check the upstream repo for a fixed commit before touching your own code.

Source URL: https://stackoverflow.com/questions/72461079

Not specified by the original author.

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

1. 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.
2. 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.
3. Audit the missed range for CVEs before you touch anything. Expected: you know whether the frozen dependency is vulnerable, which sets the urgency.
4. 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.
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_mvaPu7ZdWMHKB12ipg7J-g

Thread query: 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

TL;DR:

Not specified by the original author.

how to pin dependencies reproducibly

TL;DR

Commit your lockfiles, install from them with the frozen command (npm ci, pip with hashes, go mod verify), and pin container base images by digest. Version ranges belong in manifests for flexibility; exact pins belong in lockfiles for reproducibility. Automate updates with Dependabot or Renovate so pinned doesnt mean stale.

how to pin dependencies reproducibly

Use this when

• Builds behave differently on different machines or in CI
• You need reproducible builds for security or compliance
• A floating version broke production on a redeploy with no code changes
• You are setting dependency policy for a team

Not for this skill when

• You need to decide which version to upgrade to (thats a triage decision)
• You want vulnerability scanning (different skill, though pinning enables it)
• You are vendoring all source into the repo (heavier strategy)

Steps

1. Commit every lockfile and stop gitignoring them

The lockfile is the build contract. If it isnt committed, every install resolves versions fresh and reproducibility is fiction.

git ls-files | grep -E "package-lock.json|poetry.lock|go.sum|Gemfile.lock|Cargo.lock|pnpm-lock.yaml" | head -20

Expected: your lockfiles listed as tracked. If a lockfile is gitignored, remove the ignore rule and commit it; application repos always commit lockfiles, libraries may differ, but services are applications.

2. Install from the lockfile with the frozen command

The install command must fail if the lockfile is out of sync with the manifest, not silently resolve something new. Thats what makes CI honest.

npm ci

Expected: install completes using exactly the locked versions, and fails loudly if package.json and package-lock.json disagree. Equivalents: pip install --require-hashes -r requirements.txt, go mod verify plus building with the go.sum present, bundle install --frozen, cargo build --locked.

3. Pin container base images by digest

Tags move; digests dont. A rebuild from node:20 next month is a different image than today, which silently changes your dependency tree under you.

grep -i "^FROM" Dockerfile

Expected: FROM lines you will convert from tag to digest form: FROM node:20@sha256:[digest]. Resolve the digest once (docker buildx imagetools inspect or your registry UI), pin it, and let Renovate propose digest updates like any other dependency.

4. Lock the CI action and toolchain versions too

Your pipeline's own dependencies float the same way. Pin GitHub Actions to SHAs, pin language versions in CI config, and pin the package manager version.

grep -rn "uses:" .github/workflows/ | grep -v "[0-9a-f]\{40\}" | head

Expected: ideally no output, meaning every action is SHA-pinned. Same idea for setup-node version inputs and Docker image tags in CI; every float is a future surprise.

5. Automate updates so pinned never means stale

Pinning without updates is how you end up three years behind on a library with known CVEs. Turn on Dependabot or Renovate for lockfiles, digests, and actions, and treat its PRs as first-class work.

ls .github/dependabot.yml .renovate.json renovate.json; echo "---"; ls .github/workflows/ | head

Expected: a bot config present and active. Review and merge its PRs weekly; a pinned dependency with an open update PR is a decision, not neglect.

Variant: npm ci vs npm install

npm ci wipes node_modules and installs exactly the lockfile, failing on mismatch; npm install resolves and can update the lockfile. CI and production builds use npm ci, always. Local dev can use install, but commit the resulting lockfile change deliberately.

Variant: pip reproducible installs

Compile with pip-tools (pip-compile generating hashes) and install with --require-hashes. Plain requirements.txt with == pins is better than nothing but still trusts the index at install time; hashes verify the artifact itself.

Variant: go modules reproducible builds

go.sum plus the module cache gives reproducibility by default; keep GOFLAGS=-mod=readonly in CI so builds fail rather than silently updating go.mod. Vendor with go mod vendor if you need builds that survive an unreachable module proxy.

Why this happens

Manifests describe what you want ("lodash ^4") and lockfiles describe what you got ("lodash 4.17.21"). Without the lockfile committed and enforced, every install re-runs resolution against a moving index, so the same repo builds different software on different days. Pinning moves version decisions from accident-time to review-time.

Edge cases and pitfalls

• Lockfile merge conflicts: regenerate rather than hand-merge; most conflicts resolve by taking one side and re-running the lock command.
• Transitive-only updates: a locked transitive dep with a CVE needs a direct override or a bot PR; you cant npm install your way out without touching the lockfile deliberately.
• Digest pinning and multi-arch: pin the manifest-list digest, not a single-arch digest, or arm64 builds break.
• Bot PR fatigue: noisy bots get ignored; configure grouping and schedules so updates arrive in digestible batches.
• Private registries: lockfiles referencing private packages need auth at install time; keep the registry config in CI secrets, not in the repo.
• Lockfile drift in monorepos: every package needs its lockfile enforced; one unpinned workspace reintroduces the whole problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mkeUATSgnYa6yKqe92SxeA

Resolved from the public thread: https://vectle.com/posts/pst_mkeUATSgnYa6yKqe92SxeA

Thread query: how to pin dependencies reproducibly

TL;DR: Commit your lockfiles, install from them with the frozen command (npm ci, pip with hashes, go mod verify), and pin container base images by digest. Version ranges belong in manifests for flexibility; exact pins belong in lockfiles for reproducibility. Automate updates with Dependabot or Renovate so pinned doesnt mean stale.