pnpm/pnpm
### [`v7.29.0`](https://togithub.com/pnpm/pnpm/releases/tag/v7.29.0)
[Compare Source](https://togithub.com/pnpm/pnpm/compare/v7.28.0...v7.29.0)
##### Minor Changes
- A new setting is now supported: `dedupe-peer-dependents`.
When this setting is set to `true`, packages with peer dependencies will be deduplicated after peers resolution.
For instance, let's say we have a workspace with two projects and both of them have `webpack` in their dependencies. `webpack` has `esbuild` in its optional peer dependencies, and one of the projects has `esbuild` in its dependencies. In this case, pnpm will link two instances of `webpack` to the `node_modules/.pnpm` directory: one with `esbuild` and another one without it:
node_modules
.pnpm
webpack@1.0.0_esbuild@1.0.0
webpack@1.0.0
project1
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
project2
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
esbuild
This makes sense because `webpack` is used in two projects, and one of the projects doesn't have `esbuild`, so the two projects cannot share the same instance of `webpack`. However, this is not what most developers expect, especially since in a hoisted `node_modules`, there would only be one instance of `webpack`. Therefore, you may now use the `dedupe-peer-dependents` setting to deduplicate `webpack` when it has no conflicting peer dependencies (explanation at the end). In this case, if we set `dedupe-peer-dependents` to `true`, both projects will use the same `webpack` instance, which is the one that has `esbuild` resolved:
node_modules
.pnpm
webpack@1.0.0_esbuild@1.0.0
project1
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
project2
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
esbuild
**What are conflicting peer dependencies?** By conflicting peer dependencies we mean a scenario like the following one:
node_modules
.pnpm
webpack@1.0.0_react@16.0.0_esbuild@1.0.0
webpack@1.0.0_react@17.0.0
project1
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
react (v17)
project2
node_modules
webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
esbuild
react (v16)
In this case, we cannot dedupe `webpack` as `webpack` has `react` in its peer dependencies and `react` is resolved from two different versions in the context of the two projects.
##### Patch Changes
- The configuration added by `pnpm setup` should check if the pnpm home directory is already in the PATH before adding to the PATH.
Before this change, this code was added to the shell:
```sh
export PNPM_HOME="$HOME/Library/pnpm"
export PATH="$PNPM_HOME:$PATH"
```
Now this will be added:
```sh
export PNPM_HOME="$HOME/Library/pnpm"
case ":$PATH:" in
*":$PNPM_HOME:"*) ;;
*) export PATH="$PNPM_HOME:$PATH" ;;
esac
```
- Add `skipped` status in exec report summary when script is missing [#6139](https://togithub.com/pnpm/pnpm/pull/6139).
- `pnpm env -g` should fail with a meaningful error message if pnpm cannot find the pnpm home directory, which is the directory into which Node.js is installed.
- Should not throw an error when local dependency use file protocol [#6115](https://togithub.com/pnpm/pnpm/issues/6115).
- Fix the incorrect error block when subproject has been patched [#6183](https://togithub.com/pnpm/pnpm/issues/6183)
##### Our Gold Sponsors
##### Our Silver Sponsors
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.
This PR contains the following updates:
7.28.0
->7.29.0
Release Notes
pnpm/pnpm
### [`v7.29.0`](https://togithub.com/pnpm/pnpm/releases/tag/v7.29.0) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v7.28.0...v7.29.0) ##### Minor Changes - A new setting is now supported: `dedupe-peer-dependents`. When this setting is set to `true`, packages with peer dependencies will be deduplicated after peers resolution. For instance, let's say we have a workspace with two projects and both of them have `webpack` in their dependencies. `webpack` has `esbuild` in its optional peer dependencies, and one of the projects has `esbuild` in its dependencies. In this case, pnpm will link two instances of `webpack` to the `node_modules/.pnpm` directory: one with `esbuild` and another one without it: node_modules .pnpm webpack@1.0.0_esbuild@1.0.0 webpack@1.0.0 project1 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack project2 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack esbuild This makes sense because `webpack` is used in two projects, and one of the projects doesn't have `esbuild`, so the two projects cannot share the same instance of `webpack`. However, this is not what most developers expect, especially since in a hoisted `node_modules`, there would only be one instance of `webpack`. Therefore, you may now use the `dedupe-peer-dependents` setting to deduplicate `webpack` when it has no conflicting peer dependencies (explanation at the end). In this case, if we set `dedupe-peer-dependents` to `true`, both projects will use the same `webpack` instance, which is the one that has `esbuild` resolved: node_modules .pnpm webpack@1.0.0_esbuild@1.0.0 project1 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack project2 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack esbuild **What are conflicting peer dependencies?** By conflicting peer dependencies we mean a scenario like the following one: node_modules .pnpm webpack@1.0.0_react@16.0.0_esbuild@1.0.0 webpack@1.0.0_react@17.0.0 project1 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack react (v17) project2 node_modules webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack esbuild react (v16) In this case, we cannot dedupe `webpack` as `webpack` has `react` in its peer dependencies and `react` is resolved from two different versions in the context of the two projects. ##### Patch Changes - The configuration added by `pnpm setup` should check if the pnpm home directory is already in the PATH before adding to the PATH. Before this change, this code was added to the shell: ```sh export PNPM_HOME="$HOME/Library/pnpm" export PATH="$PNPM_HOME:$PATH" ``` Now this will be added: ```sh export PNPM_HOME="$HOME/Library/pnpm" case ":$PATH:" in *":$PNPM_HOME:"*) ;; *) export PATH="$PNPM_HOME:$PATH" ;; esac ``` - Add `skipped` status in exec report summary when script is missing [#6139](https://togithub.com/pnpm/pnpm/pull/6139). - `pnpm env -g` should fail with a meaningful error message if pnpm cannot find the pnpm home directory, which is the directory into which Node.js is installed. - Should not throw an error when local dependency use file protocol [#6115](https://togithub.com/pnpm/pnpm/issues/6115). - Fix the incorrect error block when subproject has been patched [#6183](https://togithub.com/pnpm/pnpm/issues/6183) ##### Our Gold SponsorsConfiguration
📅 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.
This PR has been generated by Mend Renovate. View repository job log here.