[rush] strictPeerDependencies are on, but do not complain if internal (inter-subspace) peers are missing
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 42/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- nodejs, typescript
- Domaine
- build-system, tooling
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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 |
- Langage dominant
- TypeScript
- Étoiles
- 6.5k
- Forks
- 708
- Merge moyen
- 4 j 7 h
- PR mergées (30 j)
- 61
Préparer son environnement
Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de microsoft/rushstack
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
microsoft/rushstack#5971 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
microsoft/rushstack#5902 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
microsoft/rushstack#5839 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
microsoft/rushstack#5683 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de microsoft/rushstack
Issues similaires
-
module-request
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
ports get and web print 'Port N already in use, trying next...' for every busy port they skipOuverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
appandflow/stim#1604 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
lingdojo/kana-dojo#31060 · 1 commentaire · 5 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
SSH workspace restore rewrites relative symlinks into the deleted sync-back staging directoryOuverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
paperclipai/paperclip#14173 ·
Les mainteneurs répondent en général sous 1 jour
-
needs-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour