Install Goa’s command-line tools using:
go install goa.design/goa/v3/cmd/goa@latest
goa gen
)goa gen <design-package-import-path> [-o <output-dir>]
The goa gen
command is the primary tool for code generation in Goa. When run,
it processes your design package and generates the complete implementation code
for your services. It recreates the entire gen/
directory from scratch,
ensuring all generated code stays in sync with your design. You should run this
command every time you make changes to your design to regenerate the
implementation code.
goa example
)goa example <design-package-import-path> [-o <output-dir>]
The goa example
command helps you scaffold your initial service
implementation. It creates example implementations and generates handler stubs
with placeholder logic to get you started. This command is meant to be run just
once when starting a new project, as it provides a foundation for your custom
implementation. Importantly, it’s designed to be safe - it won’t overwrite any
custom code you’ve already written, preserving your existing work.
goa version
)goa version
Displays the installed version of Goa.
All commands expect Go package import paths, not filesystem paths:
# ✅ Correct: using Go package import path
goa gen goa.design/examples/calc/design
# ❌ Incorrect: using filesystem path
goa gen ./design
Initialization steps for a new Goa project:
goa gen
to generate base codegoa example
to create implementation stubsDeploying the stub service early aligns your initial development with regular maintenance workflows. This approach lets you:
Once your stub service is deployed, the regular development cycle begins. This
involves implementing your actual service logic in the generated handlers,
running goa gen
whenever you make changes to your design, and continuously
testing and iterating on your implementation. This cycle ensures your
implementation stays in sync with your design while allowing you to focus on
building the core business logic of your service.
Generated code should be committed to version control rather than generated during CI/CD pipelines. Here’s why:
go get
work reliably with committed code in repositoriesgoa gen
after every design change to keep implementation in sync