Monorepo-Abhängigkeiten abstimmen
Hält gemeinsame Laufzeiten und gekoppelte Paketfamilien bei Updates über Workspaces hinweg konsistent.
monorepo-dependency-alignment
Teammitglieder mit diesem Skill
Wann ist der Skill hilfreich?
Nutze dies bei mehreren Frameworkinstanzen oder veralteten nachgelagerten Typen.
Wobei hilft er dir?
- Erfasst gemeinsame Versionen, Peer-Vorgaben und Workspace-Verbindungen.
- Gleicht Paketfamilien über vorhandene Kataloge und Konventionen ab.
- Baut in Abhängigkeitsreihenfolge und prüft Duplikate sowie alte Ausgaben.
Das könntest du fragen
Vereinheitliche React und seine Typen und prüfe abhängige Pakete mit frisch erzeugten Ausgaben. Baue das gemeinsame Paket vor Verbrauchern und prüfe aufgelöste Versionen. Erfolg darf weder auf alten Deklarationen noch doppelten React-Instanzen beruhen.
Ausführliche Dokumentation
Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.
Weniger anzeigen
Monorepo Dependency Alignment
When to Use
Use when upgrading dependencies in a repository containing multiple packages, apps, or services (packages/*, apps/*, crates/*, services/*) managed via workspaces.
The Skew Hazard in Monorepos
In a monorepo, upgrading a library in packages/ui while leaving packages/app or root package.json on an older version creates version skew:
- Dual instances of singletons (
react,vue,rxjs,graphql,zod,@opentelemetry/api,pinia) get bundled or loaded into memory simultaneously, causinginstanceoffailures, broken React hooks (Invalid hook call), or TypeScript type incompatibility (Type 'X' from node_modules/a/node_modules/pkg is not assignable to type 'X' from node_modules/pkg). - Build caches (Turborepo, Nx) and TypeScript project references (
tsc -b) break when workspace packages compile against mismatched@types/*or compiler versions.
Alignment Rules & Practices
1. Single-Version Policy for Shared Infrastructure & Peer Families
Keep shared toolchain and runtime foundation packages on a single unified version across the root manifest and every workspace package:
- Compilers & Typecheckers:
typescript,@types/node,vue-tsc,swc,esbuild,vite,rollup,webpack. - Test & Lint Tooling:
vitest,jest,playwright,eslint,prettier,biome. - Framework & State Singletons:
react,react-dom,vue,@angular/*,rxjs,graphql,zod,prisma/@prisma/client.
2. Use Workspace Catalogs & Workspace Protocols Properly
- pnpm Catalogs (
pnpm-workspace.yaml): If the repo definescatalog:orcatalogs:inpnpm-workspace.yaml(with"catalog:"references inpackage.json), update the version inpnpm-workspace.yamlso all consuming workspace packages move in lockstep. - Cargo Workspace Dependencies (
[workspace.dependencies]): When rootCargo.tomldefines[workspace.dependencies]and member crates usedep.workspace = true, update the root[workspace.dependencies]entry rather than overriding versions in individual member crates. uv/ Poetry / Composer Monorepos: Check rootpyproject.toml[tool.uv.workspace]or Composer path repositories ("type": "path").- Internal Cross-Package Links: Preserve
workspace:*,workspace:^, orworkspace:~protocols between internal packages so local workspace packages resolve to the local source tree rather than fetching a stale published version from npm/Packagist/crates.io.
3. Topological Build Order & TypeScript Project References (tsc -b)
After upgrading any dependency in a monorepo:
- Clean Stale Build Artifacts: Stale
.tsbuildinfo,dist/, or.turbocache entries can hide type errors in downstream workspace packages that re-export types from an upgraded upstream package. - Build in Topological Order: Run the workspace-wide build and typecheck (
npm run build --workspaces,pnpm -r run build,tsc -b,turbo run build typecheck,cargo check --workspace --all-targets) to verify that every downstream consumer compiles cleanly against the updated upstream package types. - Lockfile Deduplication: Run
pnpm dedupe,yarn dedupe, ornpm dedupeand inspectpnpm why <pkg> -r/cargo tree -dto confirm no unintended split resolutions remain across workspaces.
Enthaltene Dateien 1
SKILL.md
