Zarządzanie zależnościami i wersjonowanie w monorepo

In a monorepo, dozens of projects share a single tree. Without discipline, you end up with three different versions of the same library coexisting, bloating bundles and causing subtle bugs.

Centralized dependency management gives you one source of truth for versions, making upgrades and security patches a single coordinated change instead of dozens of scattered ones.

A common monorepo strategy is the single-version policy: every project depends on exactly one version of each third-party library.

• Eliminates version skew between teams
• Forces upgrades to be evaluated holistically
• Simplifies the dependency graph for build tools

The tradeoff: an upgrade can require changes across many projects at once.

Package managers like npm, yarn, and pnpm support workspaces: a top-level config that hoists shared dependencies and links internal packages locally.

Internal packages reference each other by name, not by relative path. The package manager symlinks them so a change in one is immediately visible in another.

Should you pin exact versions or allow ranges?

• Exact pins (1.4.2) give reproducible builds but require manual bumps.
• Ranges (^1.4.0) auto-pick patches but risk drift.

In monorepos, prefer exact pins plus a lockfile so every machine resolves identical trees.

The lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) records the exact resolved tree. Commit it, review changes to it, and never hand-edit it.

A surprising lockfile diff during code review is often the first sign of an unintended dependency change.

Modern tools support catalogs: a central list of versions referenced by name across packages, so you bump one place instead of many.

When internal packages are published externally, you need a release process. Tools like Changesets let contributors declare the impact of a change, then compute the next semver bump automatically.

Drift happens when versions silently diverge. Add a CI check that fails the build if duplicate versions of a critical dependency appear.

Upgrade a shared dependency in one branch, run the affected projects' tests, and merge atomically. This avoids the half-migrated state where some apps are on the new version and some are not.

Automation bots can open these upgrade PRs and let CI prove safety before merge.

Because versions are centralized, a single audit run covers the whole repo. Wire it into CI so vulnerable transitive dependencies block merges.

You learned how monorepos keep dependencies sane: a single-version policy, workspaces for linking internal packages, catalogs for centralized versions, a sacred lockfile, drift detection in CI, and coordinated, auditable upgrades.

Disciplined dependency management is what keeps a large monorepo reproducible and trustworthy.