Skip to content
stackchainstackchain

Introduction

stackchain is a config-driven Flutter scaffolding CLI. You keep it as a dev dependency, declare your preferred stack in stackchain.yaml, and generate a production-shaped app that can keep evolving.

Current package version: 1.1.3 · License: MIT · pub.dev/packages/stackchain

What is stackchain?

Section titled “What is stackchain?”

Most Flutter generators are one-shot: they dump folders once, then you are on your own. stackchain is different:

  1. Config-driven — architecture, state, routing, DI, network, and storage live in YAML.
  2. Lifecycle-aware — init, feature, rename, remove, sync, upgrade, and migrate cover the full project life.
  3. Merge-safe — managed regions use // <stackchain:id> markers so hand-written code outside them is preserved.
  4. Quality-first — every generate can run a doctor/quality gate (structure, security baseline, optional strict analyze).

Why use it?

Section titled “Why use it?”
Pain How stackchain helps
Boilerplate for every feature Vertical slices generate layered files + tests
Inconsistent folder layouts across the team One architecture key for everyone
Forgetting to register routes / DI sync and feature update managed regions
Changing Riverpod → Bloc mid-project migrate --state bloc (rewrites bootstrap too)
Renaming / removing a slice rename / remove keep yaml + router + DI aligned
Stale generated deps upgrade refreshes inferred packages + lockfile

What problems does it solve?

Section titled “What problems does it solve?”
  • Slow start — skip hand-building app/, core/, router, DI, network, and storage.
  • Feature sprawl — add slices that match your chosen architecture and state library.
  • Regeneration fear — smart merge keeps custom code outside markers.
  • Stack lock-in — migrate architecture/state/routing/DI/network intentionally.
  • Silent quality drift — gate + optional strict_quality.

Who should use it?

Section titled “Who should use it?”
  • Flutter developers building apps beyond a single screen
  • Teams that want a shared baseline (presets + CI workflow generation)
  • Maintainers who expect the stack to change over months/years

When you should not use it

Section titled “When you should not use it”
  • Throwaway prototypes with no need for structure
  • Codebases that forbid any codegen touching lib/
  • Architectures outside feature_first, clean, mvvm, mvc

Core concepts

Section titled “Core concepts”
Concept Meaning
Preset Named blueprint (production_bloc, …) that expands into defaults; explicit YAML keys win
Vertical slice A feature folder plus router/DI/tests wiring
Managed region Code between // <stackchain:ID> and // </stackchain:ID> that sync can rewrite
Lockfile .stackchain/lock.yaml records the last generated stack fingerprint
Brick Template under package bricks/ or project .stackchain/bricks/ for make / new
Quality gate Post-generate checks; doctor runs the gate alone

Mental model

Section titled “Mental model”
stackchain.yaml  →  CLI  →  templates + bricks  →  lib/ + pubspec
                              ↓
                     smart merge (regions only)
                              ↓
                     quality gate + lock.yaml

Continue with Installation or dive into How it works.