Monorepo-függőségek összehangolása
Közös futtatókörnyezetet és összetartozó csomagcsaládot tart összhangban a munkaterületek közötti frissítéskor.
monorepo-dependency-alignment
Nézd meg, miben segítMikor hasznos?
Akkor használd, ha eltérő keretrendszer-példány vagy elavult típus keletkezik.
Miben segít neked?
- Feltérképezi a közös verziót, társfüggőségi korlátot és munkaterület-kapcsolatot.
- Meglévő katalógus és munkaterületi szokás szerint igazítja a csomagcsaládot.
- Függőségi sorrendben fordít, duplázott feloldást és elavult kimenetet keres.
Például ezt kérheted
Hangold össze a Reactet és típusait, majd friss generált kimenettel ellenőrizd a függő csomagokat. A közös csomagot a fogyasztók előtt építsd, és vizsgáld a feloldott verziókat. Siker ne függjön régi deklarációtól vagy két React-példánytól.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
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.
Csomagban lévő fájlok 1
SKILL.md
