Melos: make a Flutter monorepo a product boundary

melos is useful because it focuses on workspace scripts, package graph, selective tests, and releases. The important engineering move is to place the package behind a clear boundary, so your Flutter UI depends on a stable capability rather than a vendor-shaped API.

What the library should own

• Keep package calls inside a named adapter or feature boundary.
• Make lifecycle, errors, and loading state part of a testable contract.
• Expose only the capability the app needs; hide implementation details from the whole tree.

A focused starting point

name: flutter_workspace
packages:
  - apps/**
  - packages/**

scripts:
  analyze: melos exec -- flutter analyze
  test: melos exec --fail-fast -- flutter test
  changed: melos exec --since=main -- flutter test

Production checklist

1. Read the README and changelog for the exact version you pin.
2. Add one test for lifecycle, failure, and app background/foreground behavior.
3. Verify every platform your product supports, not only the developer machine.
4. Record ownership, upgrade cadence, and rollback notes in the repository.

Common pitfall

A monorepo without ownership and dependency rules is only a larger folder; enforce boundaries in CI.

Takeaway

A good open-source library does not replace architecture. It makes one difficult boundary clearer, observable, and easier to replace.