Monorepo and Workspaces in Flutter: Benefits, Challenges, and Implementation

In recent Flutter developments, the community has started to discuss the ongoing transition toward a monorepo and the use of workspaces. This article explains what a monorepo is, why large companies adopt it, and how Flutter is applying the concept.

What is a monorepo? A monorepo (mono repository) is a code‑management strategy where multiple projects are stored in a single repository. All components, libraries, and internal dependencies live together, enabling unified versioning and easier change tracking.

Major tech companies such as Google, Meta, Microsoft, and Twitter have long used monorepos for projects like React , VSCode , and Babel . The primary reasons include simplified code management, consistent versioning, and the ability for engineers to understand dependencies across the entire codebase.

Meta’s engineers note that their monorepo contains most of the company’s code, allowing developers to quickly access any part of the system, debug across the stack, and implement fixes without dealing with version conflicts.

For Flutter, the monorepo effort aims to merge three separate repositories— flutter/engine , flutter/buildroot , and flutter/flutter —into a single flutter/flutter repository (the ongoing flutter/flaux experiment). This consolidation promises several advantages:

Atomic commits : Changes to engine, framework, and buildroot can be submitted together.

Reduced dependencies : Fewer internal version conflicts and fewer “Roll Engine” PRs.

Simplified PR workflow : Developers can modify multiple packages in a single pull request.

Easier testing : Engine and framework can be tested within the same CI pipeline.

Monorepos also eliminate version‑conflict problems because all packages share a single source of truth, and they support atomic commits for large‑scale refactoring.

Many Dart packages already use a monorepo‑style layout with tools like melos (e.g., Riverpod, Dio, Flame). Flutter’s new CI system is customized to build the merged repository efficiently.

Workspaces were introduced in Dart 3.5 to address the memory‑intensive analysis of many packages in a monorepo. By defining a workspace, multiple adjacent packages can share a single analysis context, reducing duplicated Analyzer instances and overall memory usage.

Typical workspace configuration (in pubspec.yaml ) looks like this:

name: workspace
environment:
  sdk: ^3.5.0
workspace:
  - packages/package_a
  - packages/package_b

Each package then declares resolution: workspace in its own pubspec.yaml to enable shared resolution:

name: package_a
environment:
  sdk: 3.5.0
resolution: workspace

dependencies:
  # You can depend on packages inside the workspace:
  package_b: ^1.2.4

dev_dependencies:
  test: ^1.0.0

When running flutter pub get at the repository root, a single pubspec.lock is generated for the whole workspace, and dart pub deps shows a unified dependency graph, making management much clearer.

In summary, monorepo and workspaces complement each other in Flutter. The monorepo provides a unified codebase and CI pipeline, while workspaces ensure efficient dependency resolution and memory usage across multiple Dart packages.