Flutter Modularization & Monorepos: 15 Advanced Questions

As engineering teams grow, maintaining a single giant monolith app becomes highly inefficient. Build times slow down, merge conflicts multiply, and testing changes becomes a bottleneck. This guide covers 15 essential questions and answers regarding modularization, monorepos, and package boundaries in large Flutter systems.

Questions Quick Links

• Q1. Modularization Principles
• Q2. Monorepos using Melos
• Q3. Custom Packages in pubspec.yaml
• Q4. Packages vs Plugins
• Q5. Resolving dependency versions
• Q6. Feature-Flag Routing
• Q7. Package Obfuscation rules
• Q8. Shared Memory across packages
• Q9. Loading package assets
• Q10. Micro-Frontend Mobile patterns
• Q11. Decoupled State Management
• Q12. Shared Design System Libraries
• Q13. Optimizing build_runner generation
• Q14. Peer Dependency boundaries
• Q15. Multi-Package unit coverage

Q1. What is Modularization in Flutter? Why and how should you split a large application?

Answer:

Modularization is the process of breaking a large codebase into smaller, independent, and self-contained packages. It increases reuse, keeps merge conflicts low, isolates test execution, and makes codebase structures clean.

Q2. What is a Monorepo? How does Melos help manage multi-package apps?

Answer:

A Monorepo houses multiple sub-packages (e.g. `core`, `authentication`, `dashboard`) under a single Git repository. **Melos** is a CLI tool that simplifies monorepo management: it automatically resolves local symlinks, updates versions across packages in bulk, runs automated tests in parallel, and coordinates code generation configurations.

Q3. How do you import custom local packages in pubspec.yaml?

Answer:

Use the path dependency syntax to reference the local relative folder:

dependencies:  auth_package:    path: ../packages/auth_package

Q4. What is the difference between a Package and a Plugin?

Answer:

• Package: Written in pure Dart. Contains utilities, state logic, and widgets (e.g. a shared UI component library).
• Plugin: Contains Dart APIs that bridge with platform-native code (Kotlin/Swift) to access native APIs (e.g. bluetooth, geolocation, custom notifications).

Q5. How do you manage dependency conflicts across packages?

Answer:

Create a central `core_dependencies` or `base` package that declares and exports common third-party libraries (like HTTP clients or state packages). Alternatively, use a monorepo manager like Melos to enforce unified version boundaries across all child configurations.

Q6. How do you implement feature-flag routing across packages?

Answer:

Define an abstract route provider in your `core` package. In each decoupled feature package, implement the interface to register its routes. The main app dynamically parses flags and registers only active features.

Q7. How does obfuscation apply to multi-package applications?

Answer:

Obfuscation compiles all references across all imported local packages together. The entry project running `flutter build` handles obfuscation; sub-packages do not need individual configurations.

Q8. Do imported packages run in isolated thread memory spaces?

Answer:

No. Imported local packages compile into the same application binary and run inside the main application Isolate, sharing global static instances and memory references.

Q9. How do you load assets (images, fonts) defined in a sub-package?

Answer:

Declare the assets inside the sub-package's pubspec.yaml. When loading the asset in Dart, you must specify the package name: Image.asset('assets/logo.png', package: 'auth_package');.

Q10. Can you implement Micro-Frontend patterns in Flutter?

Answer:

Yes. By isolating distinct business modules into packages, teams can develop, test, and release their modules independently in separate monorepos. The main application aggregates these packages dynamically.

Q11. How do you share authentication states across isolated packages?

Answer:

Decouple state logic by defining a clean interface (e.g. `AuthUserProvider`) in your core package. The feature packages read the interface properties while the main entry app injects the concrete implementation.

Q12. What are the best practices for design system libraries?

Answer:

Maintain a dedicated `design_system` package containing color tokens, typography rules, buttons, and input components. Exclude business logic entirely from this package to keep it reusable.

Q13. How do you optimize build_runner generation times in monorepos?

Answer:

Configure build.yaml to exclude unused files from analysis. Avoid running code generation globally; execute it on a per-package basis, or use Melos to filter and target only modified packages.

Q14. What are peer dependencies in Dart?

Answer:

When a local package depends on a shared library (like `flutter_bloc`), declare a wide compatibility constraint in its `pubspec.yaml` (e.g., `flutter_bloc: ^8.0.0`) so that the consumer app can resolve versions without conflict.

Q15. How do you aggregate unit test coverages from multiple sub-packages?

Answer:

Use Melos to run tests across all sub-packages in parallel: `melos run test:all`. Combine the generated `.lcov` files into a single coverage report using tools like `lcov-copier` or a custom CI bash script.