Melos replaces Lerna and Nx for Flutter teams

Melos manages Dart and Flutter monorepos by coordinating multiple packages in a single repository. It is in active development and works on projects such as FlutterFire and Flame. Teams leaving Lerna or Nx find that Melos understands pubspec.yaml files and pub.dev directly. Lerna, which the Nx team began stewarding in 2022, acts as a versioning and publishing layer that delegates task running and caching to Nx. Lerna serves as a companion tool many teams run on top of Nx to handle the mechanics of bumping versions and publishing packages to npm. Nx functions as a broader build platform with a plugin ecosystem for frameworks like Angular and React. Nx also provides distributed task execution across multiple CI machines via Nx Agents. Melos handles applications as easily as it handles packages. A workspace can contain Flutter applications alongside the internal packages they share. Because Melos integrates with Pub Workspaces, the Dart analyzer treats the entire monorepo as a single cohesive unit, which improves performance for code completion and error identification across all your local packages.

Melos manages applications with the same capability it uses for packages published to pub.dev. It can generate IDE run configurations for applications and list local packages and their dependencies. For CI/CD environments, GitHub users can use the Melos GitHub Action to automate complex tasks.

Setting up the Melos workspace

Melos 8.x requires Dart SDK 3.9.0 or newer. The tool relies on Pub Workspaces, a feature available since Dart 3.6.0. To set up a workspace, developers must add a list of all packages to the root pubspec.yaml file under the workspace key. Every package in the workspace needs the resolution: workspace field in its own pubspec.yaml. Melos replaces the old melos.yaml configuration with these root pubspec.yaml settings. You can skip the manual path overrides because Pub Workspaces handle local linking.

Most developers keep applications and packages in separate directories to avoid configuration conflicts in the root. If a team keeps an app in the root, they must set useRootAsPackage: true. Melos performs three functions during bootstrap: it installs package dependencies, syncs shared dependencies, and executes lifecycle scripts. To migrate from a version older than 7.0.0 to Melos 8.x.x, developers must run melos clean to remove pubspec_overrides.yaml entries. The root pubspec.yaml replaces the melos.yaml file. The packages list in the old configuration is replaced by the workspace list.

For single package projects, developers add useRootAsPackage: true to the pubspec.yaml. This allows the use of versioning and changelog generation without a monorepo. To version a private application, developers pass –all to melos version or set versionPrivatePackages: true.

Automating tasks and package versions

The melos version command automates package updates using Conventional Commits. A commit message with feat: triggers a minor version update. A fix: prefix triggers a patch version bump. If a commit contains the word BREAKING, Melos handles a major version bump. Melos versioning preserves the build number, so 1.2.3+45 becomes 1.3.0+46.

melos exec runs commands in every package. Users use the –scope flag to target specific packages by name. The –dir-exists flag includes only packages where a specific directory exists. The –depends-on flag targets packages that depend on a specific package. Melos includes several environment variables during execution, including MELOS_PACKAGE_NAME, MELOS_PACKAGE_PATH, MELOS_ROOT_PATH, and MELOS_PACKAGE_VERSION. The –no-private flag excludes packages where publish_to is set to none. The –published flag filters packages where the current local version exists on pub.dev. The –flutter flag filters packages that depend on the Flutter SDK. The –no-flutter flag selects packages that do not depend on the Flutter SDK. The –scope flag includes packages matching a name glob. The –ignore flag excludes packages matching a name glob.

The melos exec command includes a –concurrency flag to control the number of simultaneous executions. The –fail-fast flag terminates the script execution immediately if a failed test case is encountered. To run the analyzer in all packages, developers add a script item in the root pubspec.yaml and execute melos run. This command works in conjunction with the filtering options to target specific code quality checks. Developers also use Melos to merge all lcov.info files from different packages into one for code coverage reports.

Will the upcoming package:config system change how Melos handles dependency graphs?