Update pnpm to v9.9.0

[nissy-renovate-bot[bot]]

This PR contains the following updates:

Package	Type	Update	Change
pnpm (source)	packageManager	minor	9.7.1 -> 9.9.0

---

Release Notes

pnpm/pnpm (pnpm)

### [`v9.9.0`](https://redirect.github.com/pnpm/pnpm/releases/tag/v9.9.0): pnpm 9.9 [Compare Source](https://redirect.github.com/pnpm/pnpm/compare/v9.8.0...v9.9.0) #### Minor Changes - **Minor breaking change.** This change might result in resolving your peer dependencies slightly differently but we don't expect it to introduce issues. We had to optimize how we resolve peer dependencies in order to fix some [infinite loops and out-of-memory errors during peer dependencies resolution](https://redirect.github.com/pnpm/pnpm/issues/8370). When a peer dependency is a prod dependency somewhere in the dependency graph (with the same version), pnpm will resolve the peers of that peer dependency in the same way across the subgraph. For example, we have `react-dom` in the peer deps of the `form` and `button` packages. `card` has `react-dom` and `react` as regular dependencies and `card` is a dependency of `form`. These are the direct dependencies of our example project: form react@16 react-dom@16 These are the dependencies of card: button react@17 react-dom@16 When resolving peers, pnpm will not re-resolve `react-dom` for `card`, even though `card` shadows `react@16` from the root with `react@17`. So, all 3 packages (`form`, `card`, and `button`) will use `react-dom@16`, which in turn uses `react@16`. `form` will use `react@16`, while `card` and `button` will use `react@17`. Before this optimization `react-dom@16` was duplicated for the `card`, so that `card` and `button` would use a `react-dom@16` instance that uses `react@17`. Before the change: form -> react-dom@16(react@16) -> react@16 card -> react-dom@16(react@17) -> react@17 button -> react-dom@16(react@17) -> react@17 After the change form -> react-dom@16(react@16) -> react@16 card -> react-dom@16(react@16) -> react@17 button -> react-dom@16(react@16) -> react@17 #### Patch Changes - `pnpm deploy` should write the `node_modules/.modules.yaml` to the `node_modules` directory within the deploy directory [#​7731](https://redirect.github.com/pnpm/pnpm/issues/7731). - Don't override a symlink in `node_modules` if it already points to the right location [pnpm/symlink-dir#54](https://redirect.github.com/pnpm/symlink-dir/pull/54). #### Platinum Sponsors #### Gold Sponsors #### Our Silver Sponsors ### [`v9.8.0`](https://redirect.github.com/pnpm/pnpm/releases/tag/v9.8.0): pnpm 9.8 [Compare Source](https://redirect.github.com/pnpm/pnpm/compare/v9.7.1...v9.8.0) #### Minor Changes - Added a new command for upgrading pnpm itself when it isn't managed by Corepack: `pnpm self-update`. This command will work, when pnpm was installed via the standalone script from the [pnpm installation page](https://pnpm.io/installation#using-a-standalone-script) [#​8424](https://redirect.github.com/pnpm/pnpm/pull/8424). When executed in a project that has a `packageManager` field in its `package.json` file, pnpm will update its version in the `packageManager` field. #### Patch Changes - CLI tools installed in the root of the workspace should be added to the PATH, when running scripts and `use-node-version` is set. - `pnpm setup` should never switch to another version of pnpm. This fixes installation with the standalone script from a directory that has a `package.json` with the `packageManager` field. pnpm was installing the version of pnpm specified in the `packageManager` field due to this issue. - Ignore non-string value in the os, cpu, libc fields, which checking optional dependencies [#​8431](https://redirect.github.com/pnpm/pnpm/pull/8431). - Remember the state of edit dir, allow running `pnpm patch-commit` the second time without having to re-run `pnpm patch`. #### Platinum Sponsors #### Gold Sponsors #### Our Silver Sponsors

---

Configuration

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

🚦 Automerge: Enabled.

♻ 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 Renovate Bot.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
blog	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 9, 2024 0:48am

[nissy-renovate-bot[bot]]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.