[rush] strictPeerDependencies are on, but do not complain if internal (inter-subspace) peers are missing
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 42/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- nodejs, typescript
- Bereich
- build-system, tooling
Rechercherichtung
Reproduce the issue with rush update using common/config/rush/pnpm-config.json, subspaces/sdk/pnpm-config.json, and the package-a, package-b, and package-c package.json files. Start by tracing how Rush handles strictPeerDependencies across subspaces and workspace injection. Done means the missing made-up-package peer is reported for both package B and package C.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
Imagine a rush.js managed monorepo, with two subspaces, default and sdk.
strictPeerDependencies are on, in both the global config and both subspace configs.
BUT
Imagine packages A, B, C
Package A has a peerDependency for "madeUpPackage". Package A is in the SDK subspace.
Package B consumes package A. Package B does not have madeUpPackage installed. Package B is in the SDK subspace.
Package C consumes package A. Package C does not have madeUpPackage installed. Package C is in the default subspace.
When I run rush update, only complains on Package C.
But how do I make it complain about missing peer from perspective of package B
Repro steps
Expected result: rush install/update command failed
Actual result: rush install pass correctly
Details
Reproduction Setup
Monorepo Structure
monorepo/
├── rush.json
├── common/
│ └── config/
│ └── rush/
│ └── pnpm-config.json # Global config
├── subspaces/
│ ├── default/
│ │ └── pnpm-config.json # Default subspace config
│ └── sdk/
│ └── pnpm-config.json # SDK subspace config
└── packages/
├── package-a/package.json # SDK subspace - declares peerDependency
├── package-b/package.json # SDK subspace - consumes A, missing peer
└── package-c/package.json # default subspace - consumes A, missing peer
Configuration
common/config/rush/pnpm-config.json (Global):
{
"useWorkspaces": true,
"strictPeerDependencies": true
"alwaysInjectDependenciesFromOtherSubspaces": true,
}
subspaces/sdk/pnpm-config.json:
{
"useWorkspaces": true,
"strictPeerDependencies": true
}
Package Definitions
packages/package-a/package.json (SDK subspace):
{
"name": "@myorg/package-a",
"version": "1.0.0",
"devDependencies": {
"made-up-package": "^2.0.0"
},
"peerDependencies": {
"made-up-package": "^2.0.0"
}
}
packages/package-b/package.json (SDK subspace):
{
"name": "@myorg/package-b",
"version": "1.0.0",
"devDependencies": {
"@myorg/package-a": "workspace:*"
// ❌ "made-up-package" is NOT installed - should trigger error
}
}
packages/package-c/package.json (deafult subspace):
{
"name": "@myorg/package-c",
"version": "1.0.0",
"devDependencies": {
"@myorg/package-a": "workspace:*"
// ❌ "made-up-package" is NOT installed - should trigger error
}
}
Expected Behavior
Running rush update should fail and report missing peer dependencies for both Package B and Package C:
ERR_PNPM_PEER_DEP_ISSUES Unmet peer dependencies
@myorg/package-b
└─┬ @myorg/package-a
└── ✕ missing peer made-up-package@^2.0.0
@myorg/package-c
└─┬ @myorg/package-a
└── ✕ missing peer made-up-package@^2.0.0
Actual Behavior
Running rush update only complains about Package C:
ERR_PNPM_PEER_DEP_ISSUES Unmet peer dependencies
@myorg/package-c
└─┬ @myorg/package-a
└── ✕ missing peer made-up-package@^2.0.0
Package B is silently ignored, even though it has the exact same missing peer dependency.
Standard questions
Please answer these questions to help us investigate your issue more quickly:
| Question | Answer |
|---|---|
@microsoft/rush globally installed version? |
5.158.1 |
rushVersion from rush.json? |
5.158.1 |
pnpmVersion, npmVersion, or yarnVersion from rush.json? |
[email protected] |
(if pnpm) useWorkspaces from pnpm-config.json? |
yes |
| Operating system? | Mac |
| Would you consider contributing a PR? | yes |
Node.js version (node -v)? |
22.13.0 |
- Vorherrschende Sprache
- TypeScript
- Sterne
- 6.5k
- Forks
- 708
- Ø Merge
- 4 T. 7 Std.
- Gemergte PRs (30 T.)
- 61
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus microsoft/rushstack
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
microsoft/rushstack#5971 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
microsoft/rushstack#5902 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
microsoft/rushstack#5839 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
microsoft/rushstack#5683 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in microsoft/rushstack
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
melgarafael/DeskcommCRM#1812 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
prisma/prisma-cli#309 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
gregwebs/pi-quota-dispatcher#26 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
openwatersio/slackwater.xyz#124 ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent-reported area/browser area/docs documentation good first issue hacktoberfest help wanted P2
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 2 Tagen