Monorepos

Pnpm workspaces provide native support for multi-package repositories without extra tools, using a shared lockfile and efficient symlinking to save disk space.

Lerna is one of the original tools for managing JavaScript projects with multiple packages. It is now maintained by the Nx team and integrates with Nx's build engine.

A monorepo (monolithic repository) is a software development strategy where code for many projects is stored in the same repository.

In a monorepo, there is one authoritative version of shared code and configurations, preventing the "dependency hell" of mismatched versions across different repositories.

Code sharing is achieved via shared libraries, internal packages, and symlinking. This allows re-using domain logic, UI components, and utility functions across multiple applications.

Good DX is maintained via fast local execution, clear project boundaries, automated generator tools (scaffolding), and powerful IDE integrations that understand the project graph.

Building Docker images in monorepos requires careful context management. Tools like `turbo prune` or `nx docker` help extract only the necessary code for a specific service to keep image sizes small and build times fast.

The future involves tighter integration with cloud-native build farms, AI-driven graph optimization, and "virtual" monorepos that provide a single-repo feel over distributed infrastructure.

Key practices: keep libraries small and focused, use tags for project boundaries, enforce a single version policy, automate versioning/changelogs, and maintain a fast CI/CD pipeline.

Dependency management involves coordinating package versions across all projects. A common strategy is "one version rule," where all projects use the same version of a 3rd party library to avoid conflicts.

Strategies include "Fixed" versioning (all packages share one version) and "Independent" versioning (each package is versioned separately). Tools like Lerna/Changesets automate this.

Polyrepo is the traditional approach of one repository per project/service. Monorepos centralize everything, facilitating code sharing and atomic commits across projects.

Peer dependencies are crucial for libraries in a monorepo to ensure they use the host application's version of a dependency (like React or Vue) instead of bundling their own.

Migrating to a monorepo tool involves moving from ad-hoc scripts to structured task pipelines. It often starts with "wrapping" existing npm scripts and gradually adopting "integrated" build steps.

Incremental builds only recompile the projects that have changed (and their dependents), rather than the entire repository, significantly speeding up development.

Change-based testing (or "Affected" testing) uses the project graph to determine which tests need to run based on which files were modified, dramatically reducing CI time.

Hoisting is the package manager behavior of moving deeply nested dependencies to the top-level `node_modules`. While this saves space, it can lead to "phantom dependencies" where code relies on unlisted packages.

Nx is a smart, fast, and extensible build system with first-class monorepo support and powerful integrations for JS/TS, Java, Go, and more.

Task caching stores the results of expensive operations (builds, tests, linting) and replays them instantly if the inputs haven't changed.

Turborepo is a high-performance build system for JavaScript and TypeScript monorepos, focused on simplicity and extreme speed via caching.

A project graph is a visual representation of the relationships and dependencies between projects in a monorepo. Tools like Nx use this graph to optimize builds and task execution.

Bazel (Google) is an extremely powerful, language-agnostic build tool designed for Google-scale repos. Nx and Turbo are JS-centric and easier to set up, but Bazel offers unmatched performance and strictness for massive multi-language monorepos.

Optimization techniques include distributed task execution (DTE), horizontal scaling of build agents, and heavy use of remote caching to avoid re-doing work across different CI runs.

Strategies include "Atomic Deployments" (deploying all services together) or "Independent Deployments" (using tools to only deploy changed services). Independent deployment is usually required for large-scale microservice architectures.

Scaling issues include slow Git operations, IDE performance degradation, massive `node_modules` size, and complex CI/CD orchestration. Solutions include sparse checkout, virtual filesystems, and advanced build tool caching.

In a monorepo, fine-grained access control is often managed via `CODEOWNERS` files, ensuring that changes to specific projects or libraries require approval from the designated "owners."

A phantom dependency occurs when a project uses a package that is not explicitly listed in its own `package.json`, but is available due to hoisting in the `node_modules` hierarchy.

Shared libraries are packages containing reusable code (e.g., a design system or logging service) that are consumed by various apps in the monorepo. They are usually versioned and managed internally.

Remote caching shares task results across a team and CI environment. If one developer builds a library, everyone else gets the cached result instead of building it themselves.

Sparse checkout allows a developer to only cloner or check out the parts of the repository they are actually working on, reducing disk space and improving Git performance in massive monorepos.