fix: update dependency @pnpm/read-project-manifest to v5 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@pnpm/read-project-manifest (source)	^4.1.4 -> ^5.0.0

---

Release Notes

pnpm/pnpm (@​pnpm/read-project-manifest)

v5.0.2

Compare Source

Major Changes

• 🚀 33% faster installation times vs pnpm v4.

  In some cases, 2 times faster than Yarn v1! (performance diff of pnpm v4 vs v5)

  action	cache	lockfile	node_modules	npm	pnpm	Yarn	Yarn PnP
  install				43.3s	17.5s	36.7s	28.6s
  install	✔	✔	✔	7s	1.5s	735ms	n/a
  install	✔	✔		18.3s	7.8s	10.5s	1.8s
  install	✔			24.8s	10.9s	22.2s	12.1s
  install		✔		23.2s	15.2s	22.4s	13.4s
  install	✔		✔	6.4s	1.8s	17.1s	n/a
  install		✔	✔	7.3s	1.5s	735ms	n/a
  install			✔	6.4s	3.1s	33.2s	n/a
  update	n/a	n/a	n/a	7s	14.5s	42.6s	27.6s

  All the benchmarks are here.

• A content-addressable filesystem is used to store packages on the disk.

  pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage.

  For more info about the structure of this new store, you can check the GitHub issue about it.

  This change was inspired by dupe-krill and the content-addressable storage of Git.

• Reduced directory nesting in the virtual store directory.

  In pnpm v4, if you installed [email protected], it was hard-linked into node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/.

  In pnpm v5, it will be hard-linked into node_modules/.pnpm/[email protected]/. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed.

• pnpm store usages removed.

  This command was using information from the store.json files, which is not present in the new content-addressable storage anymore.

• The independent-leaves setting has been removed.

  When hoisting was off, it was possible to set the independent-leaves setting to true. When true, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment.

• The resolution-strategy setting has been removed.

  By default, the fewer-dependencies resolution strategy is used. It was possible to select a fast resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm.

• The store and the modules directory are not locked.

  We are not using directory locks anymore. So the --no-lock option will throw an error. Some users had issues with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state,
  so we removed locking.

• git-checks is true by default.

  By default, pnpm publish will make some checks before actually publishing a new version of your package.

  The next checks will happen:

  • The current branch is your publish branch. The publish branch is master by default. This is configurable through the publish-branch setting.
  • Your working directory is clean (there are no uncommitted changes).
  • The branch is up-to-date.

  If you don't want this checks, run pnpm publish --no-git-checks or set this setting to false via a .npmrc file.

• In case of a crash, the debug file will be written to node_modules/.pnpm-debug.log (not to pnpm-debug.log as in v4 and earlier).

Minor Changes

• The link-workspace-packages setting may now be set to deep.

  When link-workspace-packages is set to deep, packages from the workspace will be linked even to subdependencies.

v5.0.1

Compare Source

Major Changes

• 🚀 33% faster installation times vs pnpm v4.

  In some cases, 2 times faster than Yarn v1! (performance diff of pnpm v4 vs v5)

  action	cache	lockfile	node_modules	npm	pnpm	Yarn	Yarn PnP
  install				43.3s	17.5s	36.7s	28.6s
  install	✔	✔	✔	7s	1.5s	735ms	n/a
  install	✔	✔		18.3s	7.8s	10.5s	1.8s
  install	✔			24.8s	10.9s	22.2s	12.1s
  install		✔		23.2s	15.2s	22.4s	13.4s
  install	✔		✔	6.4s	1.8s	17.1s	n/a
  install		✔	✔	7.3s	1.5s	735ms	n/a
  install			✔	6.4s	3.1s	33.2s	n/a
  update	n/a	n/a	n/a	7s	14.5s	42.6s	27.6s

  All the benchmarks are here.

• A content-addressable filesystem is used to store packages on the disk.

  pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage.

  For more info about the structure of this new store, you can check the GitHub issue about it.

  This change was inspired by dupe-krill and the content-addressable storage of Git.

• Reduced directory nesting in the virtual store directory.

  In pnpm v4, if you installed [email protected], it was hard-linked into node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/.

  In pnpm v5, it will be hard-linked into node_modules/.pnpm/[email protected]/. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed.

• pnpm store usages removed.

  This command was using information from the store.json files, which is not present in the new content-addressable storage anymore.

• The independent-leaves setting has been removed.

  When hoisting was off, it was possible to set the independent-leaves setting to true. When true, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment.

• The resolution-strategy setting has been removed.

  By default, the fewer-dependencies resolution strategy is used. It was possible to select a fast resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm.

• The store and the modules directory are not locked.

  We are not using directory locks anymore. So the --no-lock option will throw an error. Some users had issues with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state,
  so we removed locking.

• git-checks is true by default.

  By default, pnpm publish will make some checks before actually publishing a new version of your package.

  The next checks will happen:

  • The current branch is your publish branch. The publish branch is master by default. This is configurable through the publish-branch setting.
  • Your working directory is clean (there are no uncommitted changes).
  • The branch is up-to-date.

  If you don't want this checks, run pnpm publish --no-git-checks or set this setting to false via a .npmrc file.

• In case of a crash, the debug file will be written to node_modules/.pnpm-debug.log (not to pnpm-debug.log as in v4 and earlier).

Minor Changes

• The link-workspace-packages setting may now be set to deep.

  When link-workspace-packages is set to deep, packages from the workspace will be linked even to subdependencies.

v5.0.0

Compare Source

Major Changes

• 🚀 33% faster installation times vs pnpm v4.

  In some cases, 2 times faster than Yarn v1! (performance diff of pnpm v4 vs v5)

  action	cache	lockfile	node_modules	npm	pnpm	Yarn	Yarn PnP
  install				43.3s	17.5s	36.7s	28.6s
  install	✔	✔	✔	7s	1.5s	735ms	n/a
  install	✔	✔		18.3s	7.8s	10.5s	1.8s
  install	✔			24.8s	10.9s	22.2s	12.1s
  install		✔		23.2s	15.2s	22.4s	13.4s
  install	✔		✔	6.4s	1.8s	17.1s	n/a
  install		✔	✔	7.3s	1.5s	735ms	n/a
  install			✔	6.4s	3.1s	33.2s	n/a
  update	n/a	n/a	n/a	7s	14.5s	42.6s	27.6s

  All the benchmarks are here.

• A content-addressable filesystem is used to store packages on the disk.

  pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage.

  For more info about the structure of this new store, you can check the GitHub issue about it.

  This change was inspired by dupe-krill and the content-addressable storage of Git.

• Reduced directory nesting in the virtual store directory.

  In pnpm v4, if you installed [email protected], it was hard-linked into node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/.

  In pnpm v5, it will be hard-linked into node_modules/.pnpm/[email protected]/. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed.

• pnpm store usages removed.

  This command was using information from the store.json files, which is not present in the new content-addressable storage anymore.

• The independent-leaves setting has been removed.

  When hoisting was off, it was possible to set the independent-leaves setting to true. When true, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment.

• The resolution-strategy setting has been removed.

  By default, the fewer-dependencies resolution strategy is used. It was possible to select a fast resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm.

• The store and the modules directory are not locked.

  We are not using directory locks anymore. So the --no-lock option will throw an error. Some users had issues with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state,
  so we removed locking.

• git-checks is true by default.

  By default, pnpm publish will make some checks before actually publishing a new version of your package.

  The next checks will happen:

  • The current branch is your publish branch. The publish branch is master by default. This is configurable through the publish-branch setting.
  • Your working directory is clean (there are no uncommitted changes).
  • The branch is up-to-date.

  If you don't want this checks, run pnpm publish --no-git-checks or set this setting to false via a .npmrc file.

• In case of a crash, the debug file will be written to node_modules/.pnpm-debug.log (not to pnpm-debug.log as in v4 and earlier).

Minor Changes

• The link-workspace-packages setting may now be set to deep.

  When link-workspace-packages is set to deep, packages from the workspace will be linked even to subdependencies.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.