renovate/renovate
1
0
Fork 0
mirror of https://github.com/renovatebot/renovate.git synced 2025-01-11 22:46:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

docs(dependency pinning): better alt text for images (#29350)

Browse source
This commit is contained in:
HonkingGoose 2024-05-30 21:05:44 +02:00 committed by GitHub
parent d0f58bde61
commit 66e097b784
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/usage/dependency-pinning.md
View file

@ -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.