From 66e097b7849614d106aa454c14b3016cfa15d272 Mon Sep 17 00:00:00 2001
From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Date: Thu, 30 May 2024 21:05:44 +0200
Subject: [PATCH] docs(dependency pinning): better alt text for images (#29350)

---
 docs/usage/dependency-pinning.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index 2503bb40bfdd38..8cd9129b835204 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -142,7 +142,7 @@ You can add a package rule in our Renovate configuration to group these together
 Since both `yarn` and `npm@5` both support lock files, it's a common question to ask "Why should I pin dependencies if I'm already using a lock file?".
 It's a good question!
 
-![broken-lockfile](assets/images/broken-lockfile.jpg){ loading=lazy }
+![A scary bald man in a subway carriage, surrounded with this text: when your dependencies are broken but you still got a lockfile](assets/images/broken-lockfile.jpg){ loading=lazy }
 
 Lock files are a great companion to SemVer ranges _or_ pinning dependencies, because these files lock (pin) deeper into your dependency tree than you see in `package.json`.
 
@@ -158,7 +158,7 @@ If a lock file gets out of sync with its `package.json`, it can no longer be gua
 
 The lock file has only delayed the inevitable problem, and provides much less visibility than `package.json`, because it's not designed to be human readable and is quite dense.
 
-![all-dead](assets/images/all-dead.jpg){ loading=lazy }
+![Man with goth-style hair and makeup saying: They're all dead. They just don't know it yet.](assets/images/all-dead.jpg){ loading=lazy }
 
 If the `package.json` has a range, and a new in-range version is released that would break the build, then essentially your `package.json` is in a state of "broken", even if the lock file is still holding things together.