Skip to content

Latest commit

 

History

History
379 lines (262 loc) · 8.11 KB

overview.mdx

File metadata and controls

379 lines (262 loc) · 8.11 KB
title description
Configuration overview
Configure Melos using the `pubspec.yaml` file.

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:

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:

  1. --sdk-path global command line option
  2. MELOS_SDK_PATH environment variable
  3. sdkPath in the melos section in the root pubspec.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

ide/intellij

Configuration relating to IntelliJ IDE support.

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.

command/bootstrap

Configuration for the bootstrap command.

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/**'

runPubGetInParallel

Whether to run pub get in parallel during bootstrapping.

The default is true.

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.

command/version

Configuration for the version command.

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_*

path

The path to the changelog file relative to the workspace root.

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

include

Whether to include commit bodies in the changelog. Defaults to false.

onlyBreaking

Whether to include only breaking changes in the changelog. Defaults to true.

changelogFormat

Configure the format of the generated CHANGELOG.md.

melos:
  command:
    version:
      changelogFormat:
        includeDate: true

includeDate

Whether to include the date in the generated CHANGELOG.md. Defaults to false.

With enabled, changelog entry header will include the date in the yyyy-MM-dd format.