Mason: bricks as versioned templates for Dart and Flutter projects

Four packages with distinct jobs

Mason is described as a collection of packages that enable developers to create and consume reusable templates called bricks. That word, brick, is the unit of reuse, and it is the whole point of the project.

The repository publishes four packages, and the table in the README links each to its pub.dev page.

The mason package is the one you reach for when writing a brick. The mason_api package is the layer for writing code generators in Dart, which is how a brick can produce Dart source rather than only text. The mason_cli package is the command line interface. The mason_logger package handles output formatting for all of the above.

That split is the architecture in one table. A brick is a bundle, and consuming a bundle needs a runner, while producing a bundle needs an API surface. Separating the logger keeps the CLI output consistent without every brick author reinventing it.

The primary language is Dart, and the topic list names both Dart and Flutter alongside mustache, mustache-templates and mustache-templating, so the templating engine is Mustache rather than something bespoke. The fact that flutter appears in the topic list tells you the primary use case, and the primary language tells you the primary ecosystem: this is a Dart and Flutter tool rather than a general purpose cross-language generator.

The home page is docs.brickhub.dev, which is where the full documentation lives, and the README also carries a badge endpoint for a powered by mason mark that projects can add to their own README.

Four commands from a clean machine to a generated project

The quick start is the whole user-facing workflow, and it is worth reading as a sequence because each command has a distinct role.

# 🎯 Activate from https://pub.dev
dart pub global activate mason_cli

# 🚀 Initialize mason
mason init

# 📦 Install your first brick
mason add hello

# 🧱 Use your first brick
mason make hello

The first line installs the CLI globally from pub.dev, so mason becomes available on your PATH. The second, mason init, creates the local configuration in the project you are in, which is where the list of installed bricks lives. The third, mason add hello, installs a brick by name. The fourth, mason make hello, runs the brick to generate the output.

The split between add and make is the design worth understanding. Adding a brick fetches it and records it in the project, making it a pinned, reviewable part of the repository. Making it runs it. That means a teammate clones the repository, and the brick is already there, because it was committed with the project rather than living in each developer's global configuration.

That is the difference between Mason and a shell script that copies a template directory. The brick is a dependency, with a version, and the configuration that lists it is committed.

What a brick actually contains

The repository layout gives a good answer, because a brick is a directory with a defined structure rather than a single file.

There is a bricks/ directory at the root, which holds the bricks used by the project itself, and an extensions/ directory for editor extensions. The packages/ directory holds the four published packages, one subdirectory per package. There is also tool/ for the repository's own Dart tooling, assets/ for images including the logo and the demo gif, analysis_options.yaml for the Dart analyzer configuration, cspell.config.yaml for spell checking, and a .vscode/ directory.

A brick therefore combines a Mustache template with a hook. The templating is Mustache, which means the template files are text with placeholders and the generation step substitutes values. The code generation piece comes from mason_api, so a brick can also contain Dart code that runs at generation time, which is what allows a brick to run the formatter, create files with computed names, or run package manager commands after writing the template output.

The package list is also visible in the repository: mason and mason_api, mason_cli and mason_logger, and the packages are separate pub.dev entries, so a project can depend on just the API and the logger and skip the CLI entirely, which is what you would do if you were embedding generation in a build step rather than running it by hand.

That separation is a small but real design decision. The CLI is not a dependency you have to take to use the generator.

Video tutorials and the reach problem bricks solve

The README carries an unusual amount of video material, and reading it tells you what the project is actually trying to achieve.

There is a Package of the Week episode by Flutter, an Observable Flutter session on building a Mason brick, a Meet Mason talk from Flutter Vikings 2022 introduced as an intro to templating and custom code generation, and a Mason Video Tutorial by Very Good Ventures. The names appearing here, Flutter, Flutter Community and Very Good Ventures, belong to the Flutter ecosystem's own channels, which is a stronger signal than a badge about what the tool is for.

The problem being solved is Dart and Flutter boilerplate. Every Flutter project starts with the same directory layout, the same platform folders, the same boilerplate widget files, and often the same feature module structure. Copying that between projects works until two projects drift, and then the copies are subtly different and nobody knows which is the intended one.

A brick solves that with a template that is versioned, so the structure can be updated deliberately and the update is reviewable as a diff. The template also handles the parts that a copy-paste never does: the correct package versions in pubspec.yaml, the platform registration boilerplate, and running the formatter so the generated code is not immediately flagged by the analyzer.

The Flutter Channels' involvement also means documentation and templates for common patterns come from people who work with Flutter professionally, rather than from a single author. The cost is that the tool is Dart-first, and the Mustache templating is deliberately simple, which is a reasonable trade for boilerplate but not a general purpose code generation system.

Version 0.1.x for the API, and a licence with a gap

The release history is worth reading closely, because it says something about maturity.

Three packages were released within a few hours of each other on 2026-09-15: mason_logger at 0.3.6, mason_cli at 0.1.4 and mason_api at 0.1.2. The pattern is clear. The logger, which is the presentation layer, has moved furthest and is at 0.3.x. The CLI is at 0.1.4 and the API at 0.1.2, so the surface you would build a custom generator against is still a 0.1.x release, which under Dart's own versioning conventions signals that the API may still change in breaking ways.

That is the honest caveat to plan around. The CLI workflow that most people use is likely to be stable, because the commands are few. If you are writing your own generator on top of mason_api, you are building on an API that has not yet committed to its shape.

The last push was on 2026-10-19, so the tree is current and the packages are moving together rather than one lagging behind.

On licensing, the repository shows an MIT badge in the README pointing at opensource.org/licenses/MIT, and the mason badge row also links to that licence page. The licence metadata for the repository itself is listed as unknown, so a team doing a compliance check should not rely on either the badge or the metadata field alone. The MIT badge in the README is the strongest statement the project makes about its own terms.

Editorial conclusion

Mason is worth adopting if you build Flutter or Dart projects repeatedly and want the boilerplate to be a versioned, shareable artefact rather than a copy-paste, because a brick carries its own dependencies, hooks and code generation steps with it, and the CLI installs and runs the same brick everywhere. It is the wrong tool for a team that only needs a one-off file template, since that is a job for a plain generator script, and it is the wrong choice if you cannot accept a prerelease API surface, because mason_api is published as 0.1.2 and the packages were released within a day of each other. Before you commit, read the documentation at docs.brickhub.dev, and check the bricks/ and extensions/ directories in the repository to see the shape of a real brick before you write your own.

Frequently asked questions

Official sources

1. felangel/mason on GitHub
2. Issues
3. Project website
4. README
5. Releases