refactor: always read pnpm.patchedDependencies from lockfile

[jbedard]

Why load them different when running pnpm update? That makes it inconsistent, especially with lockfile v5.3 where the lockfile vs package.json will give different results (edit: but we no longer support 5.3).

Unlike other pnpm.* properties from the package.json this one does end up in the lockfile with additional metadata, so we will always read it from the lockfile and not package.json.

---

Test plan

• Covered by existing test cases

[aspect-workflows]

Test

All tests were cache hits

190 tests (100.0%) were fully cached saving 51s.

---

Test

e2e/bzlmod

All tests were cache hits

4 tests (100.0%) were fully cached saving 467ms.

---

Test

e2e/gyp_no_install_script

All tests were cache hits

2 tests (100.0%) were fully cached saving 693ms.

---

Test

e2e/js_image_oci

All tests were cache hits

1 test (100.0%) was fully cached saving 9s.

---

Test

e2e/npm_link_package

All tests were cache hits

2 tests (100.0%) were fully cached saving 845ms.

---

Test

e2e/npm_link_package-esm

All tests were cache hits

2 tests (100.0%) were fully cached saving 773ms.

---

Test

e2e/npm_translate_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 73ms.

---

Test

e2e/npm_translate_lock_empty

All tests were cache hits

1 test (100.0%) was fully cached saving 73ms.

---

Test

e2e/npm_translate_lock_multi

All tests were cache hits

2 tests (100.0%) were fully cached saving 271ms.

---

Test

e2e/npm_translate_lock_partial_clone

All tests were cache hits

1 test (100.0%) was fully cached saving 117ms.

---

Test

e2e/npm_translate_lock_subdir_patch

All tests were cache hits

1 test (100.0%) was fully cached saving 248ms.

---

Test

e2e/npm_translate_package_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 73ms.

---

Test

e2e/npm_translate_yarn_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 73ms.

---

Test

e2e/package_json_module

All tests were cache hits

1 test (100.0%) was fully cached saving 511ms.

---

Test

e2e/pnpm_lockfiles

All tests were cache hits

6 tests (100.0%) were fully cached saving 2s.

---

Test

e2e/pnpm_workspace

All tests were cache hits

8 tests (100.0%) were fully cached saving 3s.

---

Test

e2e/pnpm_workspace_rerooted

All tests were cache hits

6 tests (100.0%) were fully cached saving 2s.

---

Test

e2e/repo_mapping

All tests were cache hits

2 tests (100.0%) were fully cached saving 451ms.

---

Test

e2e/rules_foo

All tests were cache hits

2 tests (100.0%) were fully cached saving 393ms.

---

Test

e2e/vendored_node

All tests were cache hits

1 test (100.0%) was fully cached saving 187ms.

---

Buildifier      Format

[gregmagolan]

Why load them different when running pnpm update? That makes it inconsistent, especially with lockfile v5.3 where the lockfile vs package.json will give different results.
Or should we do the opposite? Note that some package.json pnpm.* properties are never in the lockfile, so maybe all those pnpm.* properties should be read from the package.json... 🤔

I think this divergence was needed back before we failed the build when the lock file is updated. Now that we do that we should be able to just load the list of patches from the lock file

[jbedard]

I think we have to do the opposite to support other pnpm.* properties.

[gregmagolan]

🌮