Scaffold a monorepo
The scaffold command discovers common project types and writes a starting Terrabuild configuration:
terrabuild scaffold --workspace <path-to-repository>
It recognizes .NET project files, npm packages, Makefiles, Dockerfiles, and Terraform projects.
By default, scaffolding does not replace an existing WORKSPACE or PROJECT
file. Add --force only when you intend to regenerate those files.
What it creates
After discovery, the repository contains:
- one
WORKSPACEfile at the monorepo root for shared targets and extension defaults; - one
PROJECTfile in each detected buildable or deployable unit.
Typical output looks like this:
✔ PROJECT src/apps/api
✔ PROJECT src/apps/web
✔ PROJECT src/libs/shared
✔ PROJECT src/deploy
✔ WORKSPACE
Review the model before running it
Scaffolding establishes a useful baseline; it cannot infer every repository rule. Review:
- Project boundaries. Confirm each
PROJECTrepresents a meaningful unit. - Project dependencies. Add relationships that are not visible from native project files.
- Outputs. Confirm generated files and directories are described correctly.
- Targets. Remove irrelevant generated targets and add repository-specific commands.
- Deployment. Treat plans, applies, and cleanup as deliberate environment-sensitive or side-effecting work.
Discovery stops descending below a recognized project root. If an expected project is absent, check whether a parent Makefile, Dockerfile, package, or project file caused that directory to become a boundary.
Start with one outcome
Run or inspect a familiar target before modeling the entire delivery lifecycle:
cd <path-to-repository>
terrabuild explain build
terrabuild run build
Once builds and project dependencies are correct, add distribution and deployment paths. See How Terrabuild works for the model and Model a deployment for the source-to-environment path.
Use the Workspace reference and Project reference when you need the complete file syntax.