Monorepo

Nx

Full monorepo framework

Project graph, affected analysis, generators, plugins, DTE, cloud cache

Ekosystem: JS/TS, React, Node, Angular, Nest

Turborepo

Task runner + cache

Prosty w setup, szybki, remote cache, parallel execution

Ekosystem: JS/TS (agnostyczny wobec frameworków)

Bazel

Build system (Google)

Hermetic builds, massive scale (Google/Twitter), multi-language

Ekosystem: Multi-language (JS, Java, Go, Python)

pnpm workspaces

Package manager

Efektywne node_modules, workspace protocol, szybki install

Ekosystem: JS/TS ekosystem

Lerna

Monorepo management (legacy)

Klasyczny, dobry dla npm publishing, Changesets integracja

Ekosystem: JS/TS, publishing libraries

Changesets

Versioning + changelog

Semantic versioning, changelog generation, automated npm publish

Ekosystem: JS/TS libraries w monorepo

Co to jest monorepo i jakie są zalety i wady w porównaniu do polyrepo?

Monorepo to podejście gdzie cały kod organizacji (lub dużego projektu) trzymany jest w jednym repozytorium Git. Polyrepo: każdy projekt/serwis w osobnym repo. Monorepo: wszystko w jednym. Zalety monorepo: Atomic commits: zmiana API + update wszystkich klientów w jednym commit. Brak broken changes między repo. Łatwe code sharing: wspólne biblioteki, utilities, konfiguracje bez npm publish. Code reuse bez versioning overhead. Unified tooling: jeden CI/CD, jedna konfiguracja linterów, jedna wersja TypeScript. Spójne standardy. Refactoring cross-project: możesz rename symbol i zaktualizować wszystkie użycia. Ułatwione code review — wszystkie zmiany widoczne razem. Lepsze discoverability: łatwo znaleźć jak coś jest zaimplementowane w innych projektach. Wady monorepo: Wielkość repo: Google monorepo ma miliardy linii kodu — standard Git nie skaluje się. Potrzeba specjalnych narzędzi (Nx, Turborepo, Bazel). CI/CD bez optymalizacji: bez affected analysis → każda zmiana buduje wszystko. Uprawnienia: trudniej kontrolować kto ma dostęp do czego (GitHub CODEOWNERS). Onboarding: nowi developerzy muszą zrozumieć duży codebase. Kto używa monorepo: Google (jeden giant monorepo), Facebook (Sapling SCM), Microsoft, Twitter, Airbnb, Shopify. W JS/TS ekosystemie: Monorepo + workspace managery (npm workspaces, pnpm workspaces, Yarn workspaces) + Nx lub Turborepo.

Nx — jak używać do zarządzania monorepo?

Nx: najpotężniejsze narzędzie do monorepo (open-source, rozwijane przez Nrwl). Kluczowe funkcje Nx: Project Graph: Nx analizuje zależności między projektami. Wizualizacja nx graph. Affected analysis: nx affected:build — buduj tylko projekty dotknięte zmianami. Porównuje z main branch. Lokalny cache: wyniki taskow cachowane. Ten sam input = nie buduj ponownie — zwróć cache. Nx Cloud: zdalny cache współdzielony między CI i developerami. Distributed Task Execution (DTE) — rozdziel zadania między wiele agentów CI. Plugins i generators: @nx/react, @nx/node, @nx/next, @nx/nest — scaffolding i tooling. nx generate @nx/react:library my-lib — generuj nową bibliotekę z konfiguracją. Executors: predefiniowane zadania (build, test, lint, serve). Customize per projekt. Konfiguracja: nx.json — konfiguracja projektu. project.json lub package.json targets — per projekt. Structure: apps/ — aplikacje (React, Node, NestJS). libs/ — biblioteki (feature, data-access, ui, utils). Typy bibliotek: Feature libs — smart components z business logic. UI libs — dumb/presentational components. Data-access libs — API calls, state management. Utility libs — pure functions, helpers. Storybook integration: nx generate @nx/storybook:configuration. Shared Storybook dla wszystkich komponentów. Module Federation: @nx/react:host i @nx/react:remote — Module Federation z Nx. Mikro-frontendy w monorepo.

Turborepo — jak przyspieszyć build w JavaScript monorepo?

Turborepo: high-performance build system dla JavaScript/TypeScript monorepo (Vercel). Prostszy niż Nx, skupiony na szybkości. Kluczowe cechy: Incremental builds: cachuje wyniki zadań (build, test, lint). Ten sam hash inputu = nie uruchamiaj ponownie. Remote Cache: Vercel Remote Cache lub self-hosted (S3, Redis). Współdzielony między developerami i CI. Parallel execution: uruchamia zadania równolegle uwzględniając zależności. Konfiguracja: turbo.json — definicja pipeline. Pipeline dependencies: ^build — zależność od build projektów w upstream. Przykład turbo.json: pipeline.build — dependsOn ['^build'], outputs ['dist/**']. Porównanie Nx vs Turborepo: Nx — pełny framework z generators, executors, plugins, affected analysis, project graph. Lepszy dla dużych, złożonych monorepo. Turborepo — lżejszy, prostszy, skupiony na task runner + caching. Łatwiej zacząć. Można używać razem: Turborepo jako task runner + Nx project graph. pnpm workspaces: pnpm monorepo + workspace protocol (workspace:*). Efficientne node_modules (hard links, nie duplikaty). pnpm workspace catalog (pnpm 9) — centralne wersje deps. Changesets: zarządzanie wersjami i changelogami w monorepo. Dla monorepo z publikowanymi pakietami npm. Automatyczne bumping wersji + changelog generation. GitHub Actions z monorepo: path filters — uruchom CI tylko dla dotkniętych projektów. nx affected:build na CI. Turborepo --filter na CI.

Monorepo w dużych organizacjach — jak skalować?

Przy setkach projektów i dziesiątkach teamów monorepo ma specyficzne wyzwania. Git skalowanie: standard Git clone monorepo 100GB jest powolny. Sparse checkout — checkout tylko potrzebne foldery. Partial clone — nie pobieraj historii ani binariów. Shallow clone — tylko ostatnie N commitów (na CI). Git LFS — duże pliki (obrazy, modele) poza głównym repo. VFS for Git (Microsoft) — virtualizacja Git filesystem. Jj (Jujutsu) — nowy VCS, lepszy dla monorepo niż Git. Sapling (Facebook) — Git-compatible VCS dla dużego monorepo. Code Ownership: CODEOWNERS — przypisuj ownerów per folder. Automatic review requests od ownerów. Wymuszaj review od team lead przed merge do critical paths. Code review at scale: auto-approve dla małych, bezpiecznych zmian. Required reviewers per folder. Branch protection per project. Monorepo governance: style guides i linting spójne dla całego monorepo. Shared ESLint/TSConfig base configs. Nx workspace generators — standardowe szablony nowych projektów. Tech Radar wewnętrzny — które biblioteki są allowed/hold/assess. Backstage (IDP): software catalog dla monorepo. TechDocs — dokumentacja wbudowana w monorepo (docs-as-code). Visibility kto jest właścicielem czego. Migrating to monorepo: git subtree lub git subrepo — przenieś repo jako folder. Zachowanie historii commitów. Import po jednym serwisie, stopniowo.

Nx Cloud i Remote Cache — jak optymalizować CI/CD w monorepo?

Problem bez cache: 100 projektów w monorepo → jeden developer zmienia jedną utility library → CI buduje i testuje wszystkie 100. Czas: 2 godziny. Z Nx affected + cache: CI buduje tylko projekty dotknięte zmianą + cache dla już zbudowanych. Czas: 5 minut. Nx Cloud: Remote Cache: wyniki taskow (build, test, lint) uploadowane do cloud. Inny developer lub CI runner pobiera cache zamiast budować. Artefakty (dist, coverage) współdzielone. Distributed Task Execution: zamiast jeden CI runner buduje sekwencyjnie → Nx Cloud rozdziela tasks między N agentów. Dramatyczne skrócenie czasu CI. Effortless DTE: jeden workflow config → Nx Cloud zarządza agentami. Nx Cloud free tier: 500 computation hours za darmo. Paid plany dla więcej. Alternativa: Turborepo Remote Cache: self-hosted (S3, Redis, custom). Vercel Remote Cache (darmowy z Vercel). Remote Cache setup (Nx): nx-cloud.json z accessToken + nxCloudUrl. CI: NX_CLOUD_AUTH_TOKEN env variable. Metryke do monitorowania: Pipeline duration trend. Cache hit rate (cel: 80%+). Affected percentage — ile projektów dotknięte per PR. Tasks per contributor. Granularity zadań: Rozbij duże zadania na mniejsze — lepsze cache hit. Nx — możesz cache per plik nie per projekt (nx atomizer). Turborepo — cache per task output. Selective test execution: tylko testy dla dotkniętych plików (Jest --testPathPattern, pytest -k). Nx automatycznie robi to przez affected analysis.

Wyślij zapytanie