[ProjectAJ14]

What

nonstop create <name> produced four empty directories and a melos.yaml. Everything a real app needs — logging, DI, theme, routing, networking, auth — was still a day of copy-paste from the last project. This ports that groundwork into the mono-repo brick and asks which parts you want.

? Which modules should youtube start with?
❯ ◉ Network        ◉ Analytics       ◉ Developer tools
  ◉ Authentication ◉ Crash reporting ◉ Dashboard shell
  ◯ Cloud Firestore ◉ Feature flags
  ◉ Push notifications

Non-interactive: -y for the recommended set, or per module (--no-notifications --firestore). Description and org name are prompted for when not passed.

Always generated: core (logger, DI bootstrap, route observers, error types, BLoC observer), di, design_system (Material 3 theme, components, toasts, loaders), localization (type-safe strings via i69n), utils, and the app shell — bootstrap, router, splash, with no business logic.

Optional: network, auth, firestore, notifications, analytics, crashlytics, feature_flags, developer, dashboard.

How the optional modules work

A directory named {{<module>_dir}} renders to an empty path segment when its module is off, and mason skips every file underneath it. Section tags can't be used for this — {{/x}} contains a path separator — so pre_gen derives the variables instead. It also resolves the two dependencies between modules (notifications → network, developer tools → feature flags) and reports them rather than letting them fail at compile time; the CLI applies the same rules so mason make on its own still produces something that builds.

flutter create moved into pre_gen so the brick's lib/ and pubspec.yaml overlay it. post_gen formats the result — mustache line breaks depend on the answers, and a fresh project has to pass its own melos lint.

Two things worth a reviewer's attention

Process failures were silent. cli_core's trackOperation reports success as soon as the future completes, without checking the exit code — a failed flutter create or melos bootstrap showed a green tick and generation carried on to produce a half-built workspace. Fixed locally in the brick's hooks. The right home is cli_core itself, since all four bricks have this, but hooks resolve it from pub so that fix can't land until it's published.

The brick is now 2.0.0. The CLI tries BrickHub first at ^<version>; no 2.x is published there, so it falls through to the bundled copy. Publishing a 2.x brick to BrickHub later would silently take over from the bundle.

Verification

Ten module combinations, each generated end to end:

melos bootstrap / melos lint / melos test	pass on all ten
flutter build web	✓ Built build/web
Runtime boot	app reaches its first screen; shipped as a smoke test
Repo melos lint / nonstop_cli tests	SUCCESS / 18 passed

Non-Firebase projects ship apps/<name>/test/smoke_test.dart, which runs the real bootstrap.init() and pumps the app — it catches the class of bug that compiles fine and fails on device. Firebase projects can't boot before flutterfire configure, so the filename renders empty and mason drops it.

That smoke test earned its place during review, which turned up several bugs that passed analyze and melos lint cleanly: the auth screen crashed on an asset the template doesn't ship, Google/Apple buttons rendered as tofu because firebase_ui_auth never registers its own font, push notifications were never initialised when the dashboard was off, and a quote in --description produced an unparseable project.

Note on provenance

The groundwork was adapted from an existing production app. Its domain had settled into shared code — survey and health analytics groups, a survey event on core's global event bus, a hardcoded survey deep link in the notification client. All removed; verified by decoding all 222 files embedded in the generated bundle rather than grepping the source, since the bundle is what actually ships.

🤖 Generated with Claude Code