---
title: Bootstrap Command
description: Learn more about the `bootstrap` command in Melos.
---

# Bootstrap Command

<Info>Supports all [Melos filtering](/filters) flags.</Info>

This command initializes the workspace and installs remaining package
dependencies.

```bash
melos bootstrap
# or
melos bs
```

Bootstrapping has three primary functions:

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

## Why is bootstrapping required?

After the [Pub Workspaces feature](https://dart.dev/tools/pub/workspaces) 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](https://github.com/FirebaseExtended/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](/filters), therefore if you
wanted to you could bootstrap only a specific subset of your packages, for
example:

```bash
# 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 root `pubspec.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 root `pubspec.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 root `pubspec.yaml` file.

If a dependency from `environment`, `dependencies` or `dev_dependencies` in
your root `pubspec.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.

```yaml
# root pubspec.yaml
# ...
melos:
  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](/configuration/scripts#hooks)
that can be defined in your root `pubspec.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:

```yaml
# root pubspec.yaml
# ...
melos:
  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.