being short for 'repository') is a software-development strategy in which the code for a number of projects is stored in the same repository. This practice dates back to at least the early 2000s, when it was commonly called a shared codebase. Google, Meta, Microsoft, Uber, Airbnb, and X all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily changes. a software-development strategy Monorepo 10 @source: https://en.wikipedia.org/wiki/Monorepo
where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase. code reuse Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager. Collaboration across teams In a monorepo that uses source dependencies (dependencies that are compiled from source), teams can improve projects being worked on by other teams. This leads to flexible code ownership. 11 @source: https://en.wikipedia.org/wiki/Monorepo
repositories, you fetch only the project you are interested in by default. With a monorepo, you check out all projects by default. This can take up a significant amount of storage space. While some versioning systems have a mechanism to do a partial checkout, doing so defeats some of the advantages of a monorepo. Loss of version information Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning. 12 @source: https://en.wikipedia.org/wiki/Monorepo
되어가고 있다면 • 협업하는 팀원이 늘어나고 있다면 • 커스텀이 필요한 네이티브 패키지 개발이 필요하다면 • 커스텀 패키지의 소스 오픈이 제한되어 있다면 • n개의 앱(하나이상의 앱)이 동일한 로직(ex:도메인 또는 데이터 모델)을 사용하고 있다면 언제 도입하는게 적절할까요? Monorepo 13
Automated publishing of packages to pub.dev. • Local package linking and installation. • Executing simultaneous commands across packages. • Listing of local packages & their dependencies.
share a consistent set of dependencies. This forces you to resolve dependency conflicts between your grouped packages as they arise, rather than facing confusion when you start using the packages. The Flutter analyzer processes all of the packages in a pub workspace in a single analysis context, as opposed to the previous behavior of a separate context for each package. For large repositories, this can significantly reduce the amount of memory the Dart language server consumes, improving IDE performance. monorepo support Pub workspaces 19 @source: https://medium.com/dartlang/announcing-dart-3-6-778dd7a80983