Your Flutter Scripts Deserve Names

Every Flutter project eventually grows a command nobody wants to type twice.

It starts innocently:

dart run build_runner build

Then flags arrive. Platform-specific builds arrive. A native package needs a different working directory. Release preparation becomes three commands in a trench coat.

Shell history remembers all of it, but shell history is not project documentation (and mine has the filing discipline of a cat under a blanket).

Merry lets a Dart or Flutter project give those commands stable names.

Replace the incantation with a project command

Install the CLI from pub.dev:

dart pub global activate merry

Define a script:

scripts:
  build: dart run build_runner build

Then run:

merry build

Merry is a maintained fork of derry. Existing script definitions remain compatible; the CLI name changes from derry to merry. The repository preserves the upstream license and credits rather than pretending the project appeared from a particularly productive weekend.

Let the project describe its own workflow

Scripts can live directly in pubspec.yaml or in a separate merry.yaml. They can be lists, nested groups, pre/post hooks, platform-specific commands, aliases, positional arguments, and commands with their own working directory.

That means a project can encode intent:

test:
  (description): Run Flutter tests with coverage
  (scripts): flutter test --coverage

build:
  apk:
    (scripts): flutter build apk --release

The command becomes merry test or merry build apk. A contributor does not have to reverse-engineer the correct flags from CI or copy a line from last month's release notes.

merry init can write a starter configuration based on what the project actually contains. It does not generate an Android build command without an android/ directory or a code-generation command without build_runner. Existing inline scripts are left alone, and replacement of an existing script file requires confirmation.

Make the scripts visible inside VS Code

A named command is easier to remember. A browsable command is easier to discover.

The companion Merry Scripts extension adds the script tree to VS Code's Explorer. It shows nested groups and hooks, adds CodeLens actions to the YAML source, and runs a selected script in a terminal.

The extension supports both merry and derry, preferring Merry when both CLIs are available. If neither exists, it does not fake execution. It shows install guidance instead.

Merry can also generate VS Code task output:

merry ls --output=tasks

That keeps the CLI configuration as the source of truth while making the same commands available to editor workflows.

The boring command is part of the product

A script manager sounds almost too small to deserve its own tool. That is usually when repeated local conventions start drifting.

One developer runs tests with coverage. Another forgets the flag. CI uses a third version. The command still works on every machine—just not the same command.

Merry gives the workflow a name, stores it with the project, and exposes it to both humans and tools. It does not replace your shell or build system. It stops their longest sentences from becoming oral tradition.

If your README contains a section titled “Commands I Always Forget,” install Merry. The commands already have jobs. They might as well have names.