Bootstrap Command

This command initializes the workspace and installs remaining package dependencies.

melos bootstrap
# or
melos bs

Bootstrapping has three primary functions:

Installing all package dependencies (internally using pub get).
Syncing shared dependencies between packages.
Running any bootstrap lifecycle scripts.

Why is bootstrapping required?

After the Pub Workspaces feature was introduced in Dart 3.6.0, it is no longer strictly necessary to run melos bootstrap, since all the packages are already linked together. However, there are still some benefits to running melos bootstrap, if you for example want to set up shared dependencies or attaching your own setup scripts to the bootstrap hooks.

Benefits

Why would I want to use a monorepo?

All local packages in the repository can be interlinked to point to their local directories rather than 'remote' without pubspec.yaml modifications.
- Example Scenario: In a repository, package A depends on package B. Both packages A & B exist in the monorepo. However, if you pub get inside package A, pub will retrieve package B from the pub.dev registry as it's unaware of B existing locally. However, with Melos and pub workspaces, it's aware that package B exists locally too, so it will generate the various pub files to point to a relative path in the local repository.
  - If you wanted to use pub you could of course define a dependency override in the pubspec of package A that sets a path for package B but, then you'd have to do this manually every time and then manually remove it again when you want to publish or even commit your changes. This doesn't scale well and doesn't help with making a repository contributor friendly. FlutterFire for example has over 40 packages with various interlinking levels (try run melos list --graph to see its local dependency graph).
    - This can also get phenomenally worse for example say if we introduce package C that package B depends on but package C then also depends on A.
Interlinking highlights dart/analyzer issues early.
- Example Scenario: Package A relies on package B from the same mono repo. Package B gets a minor API change. Via pub get on package A the dart analyzer and IDEs report no issues with the package as it installed package B from the remote pub registry and not local (which hasn't been published yet). With Melos, the dart analyzer / IDEs would highlight this issue immediately since local versions are used. The same applies for non-breaking deprecations, package A wouldn't show there was a deprecated API in use without being interlinked through Melos.
Interlinking allows working on new, not yet published (or private) packages easily, without defining dependency overrides.

Combining with filters

Bootstrap supports all package filtering options, therefore if you wanted to you could bootstrap only a specific subset of your packages, for example:

# Only bootstrap packages that have
# changed since the main branch.
melos bootstrap --diff="main"

Bootstrap flags

The --no-example flag is used to exclude flutter package's example's dependencies (https://github.com/dart-lang/pub/pull/3856)
- This will run pub get with the --no-example flag.
The --enforce-lockfile flag is used to enforce versions from .lock files.
- Ensure .lock files exist, as failure may occur if they're not checked in.
The --no-enforce-lockfile flag is used to disregard versions from .lock files if enforce-lockfile is configured in the melos.yaml file.
The --offline flag is used to only resolve dependencies from the local cache by running pub get with the --offline flag.

In addition to the above flags, the melos bootstrap command supports a few different configurations that can be defined in your melos.yaml file.

Shared dependencies

If you want to share dependency versions between your packages in your Melos project, just add the dependencies you wish to share between the packages to your bootstrap config in your melos.yaml file.

If a dependency from environment, dependencies or dev_dependencies in your melos.yaml exists in a package, the dependency version in this package will be updated to match the version defined in your bootstrap config every time melos bootstrap is run.

# melos.yaml
# ...
command:
  bootstrap:
    environment:
      sdk: ">=3.0.0 <4.0.0"
      flutter: ">=3.0.0 <4.0.0"
    dependencies:
      collection: ^1.18.0
      integral_isolates: any
      uni_links2:
      uni_links_macos:
        git: https://github.com/SamJakob/uni_links_macos.git
    
    dev_dependencies:
      build_runner: ^2.3.3
# ...

Adding a post bootstrap lifecycle script

Melos supports various command lifecycle hooks that can be defined in your melos.yaml.

For example, if you needed to run something such as a build runner automatically after melos bootstrap is run, you can add a post hook script:

# melos.yaml
# ...
command:
  bootstrap:
    hooks:
      post: dart pub run build_runner build
# ...

This is useful to ensure any local project requirements, such as generated files being built, are met when anyone is working on your mono repo code base, e.g. external contributors.

Configuration

Commands

Guides