Configuration Overview
Every workspace requires a pubspec.yaml
file in the root. The below outlines
all the configurable fields for the melos
section of the pubspec.yaml
file.
repository
The URL of the git repository that contains the Melos workspace.
If this is defined on the top level in the pubspec file you don't have to
define it here, but if it's not just a URL you have to define it in the
melos
section, since pubspec only supports strings for the repository field.
Supported hosts:
- GitHub
- GitLab (https://gitlab.com)
- Bitbucket (https://bitbucket.org)
- Azure DevOps (https://dev.azure.com)
melos:
repository: https://github.com/invertase/melos
When using a self-hosted GitHub, GitLab, Bitbucket or Azure DevOps instance, you can specify the repository location like this:
melos:
repository:
type: gitlab
origin: https://gitlab.example.dev
owner: invertase
name: melos
sdkPath
Path to the Dart/Flutter SDK that should be used.
Relative paths are resolved relative to the root pubspec.yaml
file.
To use the system-wide SDK, provide the special value "auto".
If the SDK path is specified though multiple mechanisms, the precedence from highest to lowest is:
--sdk-path
global command line optionMELOS_SDK_PATH
environment variablesdkPath
in themelos
section in the rootpubspec.yaml
melos:
sdkPath: .fvm/flutter_sdk
ignore
A list of paths to local packages that are excluded from the Melos workspace. Do note that they are not excluded for the Dart/Flutter tooling, but only for Melos scripts.
Each entry can be a specific path or a glob pattern.
ignore:
# e.g. ignore example apps
- 'packages/**/example'
categories
Categories are used to group packages together.
To define custom package categories, add a categories
section in your root
pubspec.yaml
file. Under this section, you can specify category names as keys,
and their corresponding values should be lists of glob patterns that match the
packages you want to include in each category.
melos:
categories:
examples:
- packages/example*
alpha:
- packages/feature_a/*
- packages/feature_b
enabled
Whether to generate IntelliJ IDEA config files to improve the developer experience when working in a Melos workspace.
The default is true
.
melos:
ide:
intellij:
enabled: false
moduleNamePrefix
Used when generating IntelliJ project modules files. This value specifies a string to prepend to a package's IntelliJ module name. Use this to avoid name collisions with other IntelliJ modules you may already have in place.
The default is 'melos_'.
scripts
Define custom scripts that can be executed in the workspace via the
melos run
command.
Learn more about defining scripts here.
dependencyOverridePaths
A list of paths to local packages relative to the workspace directory that should be added to each workspace package's dependency overrides. Each entry can be a specific path or a glob pattern.
Tip: External local packages can be referenced using paths relative to the workspace root.
melos:
dependencyOverridePaths:
- '../external_project/packages/**'
runPubGetOffline
Whether to attempt to run pub get
in offline mode during bootstrapping.
Useful in closed network environments with pre-populated pubcaches.
The default is false
.
enforceLockfile
Whether to run pub get
with the --enforce-lockfile
option or not, to force getting the versions
specified in the pubspec.lock
file.
This is useful in CI environments or when you want to ensure that all environments/machines are using the same package versions.
The default is false
.
To temporarily override this melos bootstrap --no-enforce-lockfile / --enforce-lockfile
can be
used.
message
A template for the commit message, that is generated by melos version
.
Templates must use mustache syntax and have the following variables available:
new_package_versions
: A list of the versioned packages and their new versions.
The default is:
chore(release): publish packages
{new_package_versions}
command:
version:
message: |
chore: cut package releases 🎉
{new_package_versions}
branch
If specified, prevents melos version
from being used inside branches other
than the one specified.
melos:
command:
version:
branch: main
includeScopes
Whether to include conventional commit scopes in the generated CHANGELOG.md.
Defaults to true
.
melos:
command:
version:
includeScopes: false
includeCommitId
Whether to add short commit ids to commits (no links) in the CHANGELOG.md that
is generated by melos version
.
melos:
command:
version:
includeCommitId: true
linkToCommits
Whether to add links to commits in the CHANGELOG.md that is generated by
melos version
. Defaults to true
if repository
is specified.
Enabling this option, requires
repository
to be specified.
melos:
command:
version:
linkToCommits: false
workspaceChangelog
Whether to additionally build a CHANGELOG.md at the root of the workspace when
running melos version
. Defaults to true
.
melos:
command:
version:
workspaceChangelog: false
changelogs
Configure aggregate changelogs which document the changes made to multiple packages.
melos:
command:
version:
changelogs:
- path: FOO_CHANGELOG.md
description: |
All notable changes to foo packages will be documented in this file.
packageFilters:
scope: foo_*
packageFilters
Package filters to match packages that should be included in the changelog.
See Filtering Packages for all available filters.
The filter names in packageFilters
are camel cased. For example, for the
equivalent of the command line option --file-exists
use fileExists
.
description
A description to include at the top of the changelog.
If you change this value, you will need to manually update the changelog file to reflect the new description.
updateGitTagRefs
Whether to update package version tags in git dependencies of dependents when versioning packages.
See the automated releases documentation for more information.
melos:
command:
version:
updateGitTagRefs: true
releaseUrl
Whether to generate and print a link to the prefilled release creation page for
each package after versioning. Defaults to false
.
fetchTags
Whether to fetch tags from the origin
remote before versioning. Defaults to
true
.
melos:
command:
version:
fetchTags: false
changelogCommitBodies
Configuration for including commit bodies in the changelog.
melos:
command:
version:
changelogCommitBodies:
include: true
onlyBreaking: false