Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[rush] Support per-subspace pnpmVersion override in subspace-level pnpm-config.json

Abierto
  • ¿Algo no está bien?
#5,850 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
build-system, cli, tooling

Línea de trabajo

Start with Subspace.ts, pnpm-config.schema.json, and PnpmOptionsConfiguration.ts to trace configuration and fallback behavior. Then follow the listed entry points in BaseInstallManager.ts, WorkspaceInstallManager.ts, InstallHelpers.ts, RushPnpmCommandLineParser.ts, and PublishAction.ts; done means each subspace can resolve its version while global-version behavior remains unchanged.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

I'm working on many large Rush monorepos that uses the subspaces feature. Different subspaces have different needs for pnpm versions due to:

  1. Legacy subspaces that need to stay on older pnpm versions for stability
  2. New subspaces that want to adopt newer pnpm features (e.g., pnpm 11.x catalogs, improved worktree dependency handling)
  3. Gradual migration strategies where we can't upgrade all subspaces at once

Currently, rush.json has a single pnpmVersion that applies globally to the entire repository. When the subspaces feature is enabled, each subspace already has its own pnpm-config.json (for things like useWorkspaces, strictPeerDependencies, etc.), but there is no way to specify a different pnpmVersion per subspace.

This forces us to either:

  • Upgrade all subspaces simultaneously (risky for large repos)
  • Stay on an older global pnpm version and miss new features
  • Maintain separate Rush repositories (defeating the purpose of a unified monorepo)

I would like to propose that when subspaces are enabled, each subspace's pnpm-config.json should be able to optionally override the global pnpmVersion from rush.json. If not specified, it should fall back to the global version.

Details

Proposed Design

We have done an analysis of the impact and prepared a detailed implementation plan. The key points are:

1. Configuration Extension

Add an optional pnpmVersion field to pnpm-config.json (the subspace-level config file, not the global one):

// common/config/subspaces/legacy/pnpm-config.json
{
  "pnpmVersion": "8.8.0",
  "useWorkspaces": true
}

// common/config/subspaces/modern/pnpm-config.json
{
  "pnpmVersion": "11.0.0",
  "useWorkspaces": true
}

If omitted, it falls back to the global pnpmVersion from rush.json — preserving full backward compatibility.

2. Subspace-Level Resolution

Add a getPnpmVersion() method to the Subspace class that implements the priority:

public getPnpmVersion(): string {
  // 1. Subspace pnpm-config.json (if pnpmVersion is specified)
  // 2. Fallback to rush.json global pnpmVersion
}
3. pnpm-local Installation Path Isolation

Currently, InstallHelpers.ensureLocalPackageManagerAsync() installs pnpm to ~/.rush/pnpm-<version> and creates a junction at common/temp/pnpm-local.
Assume that the version of pnpm configured in rush.json is 8.8.0, whereas a subspace is configured with version 9.15.0.

We need to version-isolate the junction:

# Current:
common/temp/pnpm-local/ -> ~/.rush/pnpm-8.8.0

# Proposed:
common/temp/pnpm-local/8.8.0/ -> ~/.rush/pnpm-8.8.0
common/temp/pnpm-local/9.15.0/ -> ~/.rush/pnpm-9.15.0
common/temp/pnpm-local/ -> ~/.rush/pnpm-8.8.0

Same version across different subspaces shares the same junction.

4. Install Manager Adaptation

The following modules need to use subspace.getPnpmVersion() instead of rushConfiguration.packageManagerToolVersion:

5. Backward Compatibility
  • No subspaces enabled: Behavior is identical to today. rushConfiguration.packageManagerToolVersion and packageManagerToolFilename remain unchanged.
  • Subspaces enabled but no pnpmVersion in subspace config: Falls back to global rush.json value.
  • External plugins: They can continue using rushConfiguration.packageManagerToolVersion as the global default.
  • Autoinstallers: The can continue using rushConfiguration.packageManagerToolVersion as the global default.
  • rush add: The pnpm view command can continue using rushConfiguration.packageManagerToolVersion as the global default.
6. Known Constraints (acceptable trade-offs)
  • pnpm-sync cross-version inject dependencies: Not supported for the first iteration. We can add a validation that cross-subspace injected dependencies require the same pnpm version across involved subspaces.
  • rush-pnpm CLI: Already supports --subspace, so it naturally maps to the correct version once the above changes are made.
Full Impact Analysis with AI

Have identified 10 categories, 30+ files/modules affected.

A quick summary of the most impactful files:

Category Key Files Nature of Change
Config pnpm-config.schema.json, PnpmOptionsConfiguration.ts Add pnpmVersion field
Data Model Subspace.ts, RushConfiguration.ts Add getPnpmVersion(), fallback logic
Install InstallHelpers.ts Version-parameterized ensureLocalPackageManagerAsync()
Install Manager BaseInstallManager.ts All version checks → subspace version
Install Manager WorkspaceInstallManager.ts packageManagerFilename → subspace path
CLI RushPnpmCommandLineParser.ts All version checks → _subspace.getPnpmVersion()
Utilities PackageJsonUpdater.ts, SetupChecks.ts Batch by subspace or global fallback
Plugins rush-resolver-cache-plugin Version check → subspace version

Standard questions

Question Answer
@microsoft/rush globally installed version? 5.172.1
rushVersion from rush.json? 5.172.1
pnpmVersion, npmVersion, or yarnVersion from rush.json? [email protected]
(if pnpm) useWorkspaces from pnpm-config.json? true
Operating system? Mac
Would you consider contributing a PR? Yes
Node.js version (node -v)? 22.21.0
Lenguaje dominante
TypeScript
Estrellas
6.5k
Forks
708
Merge medio
2 d 1 h
PR fusionados (30 d)
46

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/rushstack

Todos los issues de microsoft/rushstack

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.