Melos for Dart and Flutter multi-package workspaces

Melos scope for Dart and Flutter repositories

Melos addresses the operational problem that appears after a Dart or Flutter codebase is divided into independently versioned packages. Code sharing becomes easier in that arrangement, but a change may affect several package manifests, tests, release notes, and published artifacts. Melos provides one command-line layer for running work across that repository and for coordinating releases. Its intended users are Dart and Flutter maintainers, including teams that keep applications beside internal libraries or that publish packages to pub.dev.

The project applies to more than conventional monorepos. According to the README, a workspace can contain Flutter applications, Dart applications, shared packages, or a mixture of them. It can also serve a repository containing only one application or package when the maintainer wants scripts, versioning, changelog generation, or publishing without publishing anything at all. That narrower use is useful, but it means Melos is not exclusively a multi-package package manager.

Melos also generates IDE run configurations for applications, as stated in the README. The repository includes a `.vscode/` directory, and the project description identifies IntelliJ and Visual Studio Code support. The README does not provide enough detail here to describe the generated file names or exact IDE configuration contents, so those details should be checked in Melos documentation before relying on them for editor automation.

The project is written primarily in Dart and distributed under the Apache-2.0 license. The repository is not archived, and its last push was on 2026-10-16. There are no GitHub releases listed, which means release discovery through GitHub Releases is not a practical upgrade path for adopters. The documentation and `CHANGELOG.md` are the more relevant project-specific references when tracking changes.

Pub workspaces underneath Melos command orchestration

Melos 8.x.x is built on Dart's pub workspaces rather than maintaining its own generated dependency override files. The root `pubspec.yaml` contains a `workspace` list, and each participating package declares workspace resolution in its own manifest. This changes the architecture substantially from Melos versions older than 7.0.0. The former `melos.yaml` is no longer the configuration source, and the former package list is replaced by the root pub workspace list.

Melos uses the resulting package structure to execute scripts and commands across packages. The README says that scripts, tests, and analysis can run across a workspace, with package filtering available. Configuration remains rooted in the repository's pub manifests. The example places development tooling and the `melos` configuration section at the root, while application and package manifests participate through `resolution: workspace` and entries under `workspace`.

Release automation is based on Conventional Commits. The project documentation says it can calculate version changes, update changelogs, retain and increment integer build numbers, and publish relevant packages. This responsibility is distinct from dependency linking. Melos links the repository through pub workspaces, then adds repository-level operations around package execution and release management.

There is an SDK-dependent limitation. Workspace globs are supported starting with Dart SDK 3.11.0. With an older compatible SDK, the workspace entries must be listed manually. That restriction matters for teams that want broad patterns such as selecting a family of package directories. The migration example uses explicit paths, so it remains valid without relying on glob support.

Melos 8 installation and first workspace setup

The README does not include a fresh installation command or package installation step. It directs users to the documentation at `https://melos.invertase.dev/~melos-latest`, so the exact initial setup procedure must be confirmed there. It does show the root configuration used after migration to Melos 8.x.x. The following excerpt comes directly from the README and defines a workspace with three explicit package paths:

name: my_workspace
publish_to: none
environment:
  sdk: ^3.9.0
workspace:
  - packages/helper
  - packages/client_package
  - packages/server_package
dev_dependencies:
  melos: ^8.0.0
melos:
  # All of the content of your previous melos.yaml file
  # (Except for the packages and name)

The root is marked with `publish_to: none`, so the workspace container itself is not a publishable pub.dev package. Each child package still needs its own manifest and the migration instructions require `resolution: workspace` in every package `pubspec.yaml`. The `melos` section replaces the old Melos-specific configuration file, except for the obsolete `packages` and `name` entries.

For an existing project created before Melos 7.0.0, the first documented cleanup operation removes generated override entries. The command is:

melos clean

The README says to run that before moving configuration into the root pub manifest. A new workspace has no equivalent bootstrap command documented in the README, so this example should not be treated as a complete first-run installation tutorial. After the manifests are configured, the first useful validation is to run a script already defined under `melos` or use the documentation to create one. The excerpt does not define a script command, so inventing one would go beyond the documented configuration.

Cross-package scripts and the Melos 8 exec rule

Melos scripts let a repository define a command once and execute it against workspace packages. The README explicitly covers scripts, tests, and analysis, along with filtering. This is useful when a Dart SDK check, analyzer invocation, or test entry point must run consistently across several packages. The workspace must already contain the package manifests because Melos builds its operations on pub workspaces.

Melos 8.x.x changes how script options are represented. The `run` and `exec` keys are mutually exclusive. Commands that need execution options now belong under `exec`, with the shell command stored under its `command` key. The README gives this migration:

scripts:
  test:
    exec:
      command: dart test --concurrency=1
      concurrency: 1

This replaces the older form, which placed `dart test --concurrency=1` under `run` and the execution setting under `exec`. Teams that keep a large script catalog should check this distinction during migration rather than copying old definitions unchanged.

The README does not show package filter syntax, command output, or a complete new-project script declaration. Those details should come from the configuration reference instead of being inferred. The confirmed point is architectural: Melos sits above pub workspaces and coordinates package operations, while individual scripts invoke Dart or Flutter tooling.

A workspace does not need to be published to use these script capabilities. This separates day-to-day repository automation from the release path. If publishing is not part of the workflow, the Conventional Commit versioning and pub.dev publication features can remain outside the adoption decision.

Versioning, build numbers, changelogs, and pub.dev publishing

Melos uses Conventional Commits to connect commit history with package release decisions. According to the README, this supports automated versioning, changelog generation, and publishing for packages hosted on pub.dev. That makes Melos different from pub workspaces alone: pub workspaces define local package relationships, while Melos adds release operations that understand Dart package structure and `pubspec.yaml` files.

Version handling has changed in ways that can alter release output. Starting with Melos 8.0.0, `melos version` retains and increments integer build numbers. The documented example changes `3.0.0+11` to `4.0.0+12`, rather than producing `4.0.0`. A patch release below version 1.0.0 bumps the patch component, so `0.1.0` becomes `0.1.1`, not `0.1.0+1`. Maintainers with release automation that expects the old output need to verify their version checks and build-number handling before running a release command.

The README does not specify rollback behavior, credentials configuration, dry-run output, or the exact failure behavior when pub.dev rejects a package. It also does not document signing, protected publishing, or credential storage. Those subjects require verification in the release documentation and pub.dev configuration before production use.

Melos remains optional at runtime after setup. The README states that nothing has to be published to use the tool, and a repository can contain applications without releasing them. Automatic publishing is therefore a capability rather than a prerequisite.

Melos 7 migration and root-package trade-offs

Melos 8 migration removes a maintenance mechanism that older versions used. Projects below 7.0.0 could contain generated `pubspec_overrides.yaml` entries. The documented migration begins with `melos clean`, then asks maintainers to add `resolution: workspace` to every package, enumerate packages in the root `pubspec.yaml`, and move former `melos.yaml` content under the root `melos` key.

This is more than a file move. The package list changes ownership, package manifests declare workspace resolution, and scripts may need `run` and `exec` consolidation. Repositories that used old Melos behavior should compare their existing configuration against each migration item before upgrading.

Repository layout adds another decision. If the repository root was also a package, the README documents `useRootAsPackage: true` as a way to preserve that behavior. Otherwise, maintainers can restructure the project so the main application lives in a subdirectory. The option is a migration bridge, not a fully described compatibility guarantee in the README. Its detailed behavior is linked to the Configuration Overview rather than explained there.

The main operational cost comes from coordination. One new package requires a workspace entry, workspace resolution, and potentially updated scripts or release expectations. Explicit package lists also grow with repository size until Dart SDK 3.11.0 permits globs. A team that accepts this maintenance can gain centralized release handling, but a small collection with a simple dependency graph may not need that layer.

Melos compared with Nx, Rush, Changesets, and plain pub workspaces

Melos occupies a different ecosystem position from general-purpose JavaScript and Rust workspace tools. Nx and Turborepo coordinate tasks for JavaScript and TypeScript repositories, while Rush provides a package-based monorepo workflow. Melos instead understands Dart and Flutter packages, `pubspec.yaml`, pub.dev, and Flutter application versioning. Using one of those tools in a Dart repository would not supply the Dart-specific behavior described in this project.

Changesets, semantic-release, and release-please provide release automation in other ecosystems. Melos combines release work with Dart workspace execution and package filtering. The relevant distinction is not merely command count. It is the project model: Melos can identify Dart and Flutter packages, generate application run configurations, preserve build numbers in Dart-style versions, and publish to pub.dev.

Plain pub workspaces are the closer lower-scope alternative. The README says Melos builds on pub workspaces, which handle local package linking. If a repository needs dependency resolution across packages but does not need cross-package scripts, changelog generation, Conventional Commit versioning, or pub.dev publication, pub workspaces alone are the more direct choice. Melos becomes relevant when those repository operations justify an additional tool and configuration layer.

IDE support is also part of the decision, but the README does not document generated run configuration formats. Engineers relying on a specific IntelliJ or Visual Studio Code workflow should inspect that documentation rather than infer behavior from the `.vscode/` directory.

Editorial conclusion

Adopt Melos when one Dart or Flutter repository contains multiple related packages or applications and you need centralized scripts, release handling, and pub.dev publishing. Do not choose it merely to link a single package, because pub workspaces already cover that narrower need. Before upgrading an existing Melos 7 or earlier setup, first verify that every package can add `resolution: workspace`, the root package list is complete, and all `run` and `exec` script definitions satisfy the mutually exclusive rules introduced in Melos 8.x.x.

Frequently asked questions

Official sources

1. invertase/melos on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README