Make Command Reference

This page is the exhaustive lookup for commands that create controllers, commands, jobs, schedules, events, models, migrations, and named queues. Each entry records the files and registration points the command changes.

Use the linked feature guide when you need to implement the generated resource. Use this reference when you need exact placement, wiring, removal, or shared-option behavior.

In a multi-app Project, run make commands through the app that owns the resource:

forj admin make:controller users
forj admin make:job reports:export
forj admin make:schedule audit:cleanup

The app prefix chooses the registration point. forj admin make:* creates the generated resource under internal/... and writes the registration and Wire changes into app/admin/...; unprefixed forj make:* creates the resource under internal/... and writes registration changes to the default app under app/....

This keeps app composition in the owning app while shared domain code can still live under internal/....

Choose a Command or Workflow

• make:controller creates an HTTP controller and registers its routes.
• make:app creates an additional runnable app.
• make:command creates an App command and exposes it to Kong.
• make:job creates a queue job and registers its handler.
• make:queue creates named queue configuration and a generated accessor.
• make:schedule creates and registers a recurring task.
• make:event creates a typed application event.
• make:subscriber creates and registers an event subscriber.
• make:model derives a model and repository from a database table.
• make:migration creates timestamped up and down SQL files.

Shared workflows apply across those generators:

• Package placement explains grouped names and feature ownership.
• Removing generated resources previews and reverses managed changes.
• Opening generated files opens the primary generated source in your editor.
• Output overrides selects a non-default package directory.
• Ownership and verification separates generated scaffolding from App behavior and proves the result.

Command Reference

Some make commands are native GoForj commands and some are App commands. During development, use the same forj prefix for both. Native GoForj commands win on name collisions; otherwise GoForj delegates to the active app through the same source-aware path as forj run.

For an additional app, prefix the command with the app name. The generated resource stays under internal/..., while registration changes go to the owning app under app/<name>/....

make:app

Create an additional app:

forj make:app admin

Without selection flags in an interactive terminal, the command opens the app wizard. In non-interactive use, or when scripting an exact selection, pass flags:

forj make:app admin --components web-api,jobs
forj make:app statuspage --components web-api,web-ui --starter-kit vue

Use --without to remove components from the project-derived default selection. Use --help-format framework, --help-format external_cli, or --help-format guided to choose the App command-help style. --skip-wire renders the App files without regenerating Wire; it is intended for generator debugging or a workflow that deliberately runs Wire separately.

The command creates the conventional binary entrypoint under cmd/admin/, app-owned composition under app/admin/, and app-specific Wire graph under app/admin/wire/. Exact files depend on the selected components; a CLI-only app does not receive HTTP, scheduler, or worker files merely because another app has them.

It also records the app's render metadata under top-level apps in .goforj.yml:

apps:
  admin:
    components: [web_api, jobs]
    starter_kit: none

The interactive wizard enrolls an app with HTTP, jobs, or schedules in forj dev and proposes the combined run command. A CLI-only app remains unenrolled. Review the Dev Run step when the app needs a narrower long-running command.

Flag-driven and non-interactive creation do not enroll the app unless --dev-run is explicit:

forj make:app admin --components web-api,jobs --dev-run run

--dev-run run selects the development supervisor command; it does not add runtime capabilities. A runtime-capable binary already defaults to run when launched without arguments.

Remove only the conventional App files and metadata created by make:app with:

forj make:app admin --remove

Removal is conservative and does not delete unknown app-owned files or migration history. See Apps for the ownership model and forj dev for normal lifecycle configuration.

make:controller

Generate an HTTP controller for the package that owns the route.

forj make:controller reports

The name controls both the package path and the starter route, /reports.

Prefix the command when an additional app owns the route:

forj admin make:controller users

Remove the generated controller and its managed registrations with:

forj make:controller reports --remove

internal/reports/controller.go               created
app/wire/inject_http_controllers_app.go      provider added
app/routes.go                                routes registered

For an additional app, the generated controller stays under internal/...; the two registration files live under the owning app's app/<name>/....

In existing-file excerpts, highlighted lines are injected by this command.

The generated controller includes a constructor, starter route, and replaceable handler:

internal/reports/controller.go

// Controller handles HTTP requests.
type Controller struct {
	logger *logger.AppLogger
}

// NewController creates a Controller.
func NewController(logger *logger.AppLogger) *Controller {
	return &Controller{logger: logger}
}

// Routes returns the HTTP routes handled by Controller.
func (c *Controller) Routes() []web.Route {
	return []web.Route{
		web.NewRoute(http.MethodGet, "/reports", c.Get),
	}
}

// Get handles the controller's GET route.
func (c *Controller) Get(r web.Context) error {
	c.logger.Info().Msg("Hello from reports controller")
	return r.Text(http.StatusOK, "Hello from reports controller")
}

The HTTP controller Wire set gains the constructor:

app/wire/inject_http_controllers_app.go

// appHttpControllerSet provides all HTTP route controllers.
var appHttpControllerSet = wire.NewSet(
	reports.NewController,
)

The App route registry receives the controller and appends its routes:

app/routes.go

// ProvideRoutes provides route groups for the HTTP server.
func ProvideRoutes(
	reportsController *reports.Controller,
) []web.RouteGroup {
	publicRoutes := slices.Concat(
		reportsController.Routes(),
	)
	return []web.RouteGroup{
		web.NewRouteGroup("/api/v1", publicRoutes),
	}
}

make:command

Generate an App command.

forj make:command reports:sync

Use --name to override the exposed command signature independently from the generated type and file:

forj make:command Sync -d ./internal/billing/reports --name reports:sync

forj make:command reports:sync --remove

internal/reports/sync_cmd.go      created
app/wire/inject_cmd_app.go        provider added
app/commands.go                   command exposed

In existing-file excerpts, highlighted lines are injected by this command.

The command keeps its CLI metadata with its implementation:

internal/reports/sync_cmd.go

// SyncCmd handles the reports:sync app command.
type SyncCmd struct {
	logger *logger.AppLogger
}

// Signature keeps command metadata with the implementation so generated wiring stays package-local.
func (*SyncCmd) Signature() string {
	return `name:"reports:sync" help:"Sync command"`
}

// Run is the entrypoint Kong calls after parsing reports:sync.
func (c *SyncCmd) Run(ctx context.Context) error {
	_ = ctx
	c.logger.Info().Msg("SyncCmd executed!")
	return nil
}

The App Wire set gains the provider:

app/wire/inject_cmd_app.go

// appCommandSet provides app-owned command providers.
var appCommandSet = wire.NewSet(
	reports.NewSyncCmd,
)

The App command collection exposes it to Kong:

app/commands.go

// Commands wires application-specific commands into the CLI.
type Commands struct {
	ReportsSyncCmd reports.SyncCmd `cmd:""`
}

make:job

Generate a queue job and select its default queue.

forj make:job billing:sync-reports --queue billing

forj make:job billing:sync-reports --remove

internal/billing/sync_reports_job.go    created
app/wire/inject_jobs_app.go             provider and handler added

In existing-file excerpts, highlighted lines are injected by this command.

The generated dispatch helper targets the selected queue:

internal/billing/sync_reports_job.go

// SyncReportsJobTypeName identifies the job during dispatch and handler registration.
const SyncReportsJobTypeName = "billing:sync-reports"

// SyncReportsJobPayload is the payload for the SyncReportsJob job.
type SyncReportsJobPayload struct {
	// add your payload fields here
}

// SyncReportsJob dispatches and handles its queue workflow.
type SyncReportsJob struct {
	queues *queues.Manager
}

// NewSyncReportsJob constructs the job with the configured queue manager.
func NewSyncReportsJob(queues *queues.Manager) *SyncReportsJob {
	return &SyncReportsJob{queues: queues}
}

// Queue dispatches the typed payload to the selected queue.
func (t *SyncReportsJob) Queue(ctx context.Context, payload SyncReportsJobPayload) error {
	data, err := json.Marshal(payload)
	if err != nil {
		return err
	}
	_, err = t.queues.WithContext(ctx).Dispatch(
		queue.NewJob(SyncReportsJobTypeName).Payload(data).OnQueue("billing"),
	)
	return err
}

// HandleTask processes queue payloads.
func (t *SyncReportsJob) HandleTask(_ context.Context, msg queue.Message) error {
	var p SyncReportsJobPayload
	if err := msg.Bind(&p); err != nil {
		return fmt.Errorf("json.Unmarshal failed: %w", err)
	}
	return nil
}

The job Wire file gains both construction and runtime registration:

app/wire/inject_jobs_app.go

// appJobSet provides app-owned jobs and their runtime registration.
var appJobSet = wire.NewSet(
	registerJobHandlers,
	billing.NewSyncReportsJob,
)

// registerJobHandlers binds every application job to each configured queue runtime.
func registerJobHandlers(
	queueManager *queues.Manager,
	billingSyncReportsJob *billing.SyncReportsJob,
) *jobHandlerRegistration {
	queueManager.Register(
		billing.SyncReportsJobTypeName,
		billingSyncReportsJob.HandleTask,
	)
	return &jobHandlerRegistration{}
}

make:queue

Add a named queue resource.

forj make:queue reports --workers 2

Run forj make:queue without a name in an interactive terminal to use the resource wizard.

Use --name production-report-jobs when the backend queue name should differ from the reports resource name. Use --env-file to update a file other than .env.

forj make:queue reports --remove

Pass the same --env-file during removal when creation did not update .env.

.env                               named queue keys added
internal/queues/accessors_gen.go   regenerated on build

With --env-file, the specified file replaces .env. No Wire file changes.

In existing-file excerpts, highlighted lines are injected by this command.

The queue resource is environment configuration:

.env

QUEUE_REPORTS_NAME=reports
QUEUE_REPORTS_WORKERS=2

Using --name production-report-jobs changes the first value while the stable resource key remains REPORTS.

The next forj build or forj generate --queue derives a typed accessor from that resource key:

internal/queues/accessors_gen.go

// Reports returns the "reports" queue instance.
func (m *Manager) Reports() *queue.Queue {
	return m.reports
}

That is the complete make:queue output: environment configuration plus the accessor produced by the next build or queue generation pass. The following application-owned example shows how a generated job can use that named queue; make:queue does not write the job, service, Wire registration, or controller.

Keep the payload beside the generated job and its handler:

internal/reports/generate_job.go

// GenerateJobTypeName identifies the job during dispatch and handler registration.
const GenerateJobTypeName = "reports:generate"

// GenerateJobPayload is the durable contract passed to the report worker.
type GenerateJobPayload struct {
	ReportID string `json:"report_id"`
}

// GenerateJob handles queued report generation through the application service.
type GenerateJob struct {
	service *Service
}

// NewGenerateJob constructs the worker with the service that owns report generation.
func NewGenerateJob(service *Service) *GenerateJob {
	return &GenerateJob{service: service}
}

// HandleTask decodes the queue message and delegates report generation to the service.
func (j *GenerateJob) HandleTask(ctx context.Context, msg queue.Message) error {
	var payload GenerateJobPayload
	if err := msg.Bind(&payload); err != nil {
		return fmt.Errorf("bind generate report payload: %w", err)
	}
	return j.service.Generate(ctx, payload.ReportID)
}

This example carries an ID because the worker should load the report's current state. That is a good default for mutable records, not a rule for every workload. For high-throughput work, use a bounded batch of IDs or a compact immutable snapshot DTO when avoiding another read matters. Avoid placing persistence models directly on the queue: they tend to create large payloads, stale state, and a queue contract coupled to the database model.

make:queue does not create an application service. Inject the queue manager into the service that dispatches the job:

internal/reports/service.go

// Service coordinates report persistence, rendering, and asynchronous dispatch.
type Service struct {
	queues   *queues.Manager
	reports  *Repository
	renderer *Renderer
}

// NewService constructs the report service with its queue and domain dependencies.
func NewService(
	queues *queues.Manager,
	reports *Repository,
	renderer *Renderer,
) *Service {
	return &Service{
		queues:   queues,
		reports:  reports,
		renderer: renderer,
	}
}

// QueueGeneration dispatches report work through the named reports queue.
func (s *Service) QueueGeneration(ctx context.Context, reportID string) error {
	payload, err := json.Marshal(GenerateJobPayload{ReportID: reportID})
	if err != nil {
		return err
	}

	reports := s.queues.Reports()
	_, err = reports.WithContext(ctx).Dispatch(
		queue.NewJob(GenerateJobTypeName).Payload(payload),
	)
	return err
}

// Generate reloads the report before rendering so the worker uses current state.
func (s *Service) Generate(ctx context.Context, reportID string) error {
	report, err := s.reports.Find(ctx, reportID)
	if err != nil {
		return err
	}
	return s.renderer.Render(ctx, report)
}

Register that constructor with the application service set:

app/wire/inject_services_app.go

// appSet provides application services to Wire.
var appSet = wire.NewSet(
	reports.NewRenderer,
	reports.NewService,
)

Wire can then inject the service into a controller, command, job, or other application entry point:

internal/reports/controller.go

// Controller exposes report operations over HTTP.
type Controller struct {
	service *Service
}

// NewController constructs the HTTP adapter with the report service.
func NewController(service *Service) *Controller {
	return &Controller{service: service}
}

// Generate queues report generation and returns without waiting for the worker.
func (c *Controller) Generate(r web.Context) error {
	if err := c.service.QueueGeneration(r.Context(), r.Param("reportID")); err != nil {
		return err
	}
	return r.NoContent(http.StatusAccepted)
}

The dependency direction stays one-way: the reports package imports internal/queues, while the App's Wire package imports reports and assembles the graph.

Omit OnQueue when dispatching through the direct handle. When application code needs GoForj to translate the logical queue name to an App-prefixed backend name, dispatch through the injected manager and use .OnQueue("reports") instead.

make:schedule

Generate a recurring task.

forj make:schedule reports:daily --every 24h

forj make:schedule reports:daily --remove

If --every is omitted, the generated starter interval is 1h.

internal/reports/daily_schedule.go      created
app/wire/inject_schedules_app.go        provider and AppSchedules entry added

In existing-file excerpts, highlighted lines are injected by this command.

The generated task keeps the schedule identity, interval, and work together:

internal/reports/daily_schedule.go

// DailySchedule is a scheduled task.
type DailySchedule struct{}

// NewDailySchedule creates a new DailySchedule.
func NewDailySchedule() *DailySchedule {
	return &DailySchedule{}
}

// Name returns the operational schedule name.
func (s *DailySchedule) Name() string {
	return "reports:daily"
}

// Interval returns how often the schedule should run.
func (s *DailySchedule) Interval() (time.Duration, error) {
	return time.ParseDuration("24h")
}

// Handle runs the scheduled task.
func (s *DailySchedule) Handle(ctx context.Context) error {
	return nil
}

Wire constructs the schedule and adds it to the App's schedule collection. The highlighted lines are injected:

app/wire/inject_schedules_app.go

// appScheduleSet contains application-owned schedule providers.
var appScheduleSet = wire.NewSet(
	ProvideAppSchedules,
	app.NewScheduleRegistry,
	wire.Bind(
		new(schedules.ScheduleRegistry),
		new(*app.ScheduleRegistry),
	),
	reports.NewDailySchedule,
)

func ProvideAppSchedules(
	dailySchedule *reports.DailySchedule,
) *schedules.AppSchedules {
	return schedules.NewAppSchedules(
		dailySchedule,
	)
}

The App already contains the handoff that makes those entries automatic. make:schedule does not modify this file:

app/schedules.go

// Register attaches app schedules to the scheduler.
func (r *ScheduleRegistry) Register(s *schedules.Scheduler) error {
	if err := r.appSchedules.Register(s); err != nil {
		return err
	}
	return nil
}

AppSchedules.Register iterates the collection and registers each task using its Name, Interval, and Handle methods. Manually defined fluent schedules can still follow that call when they need cron expressions, calendar helpers, or other custom registration.

make:event

Generate an application event type.

forj make:event billing:invoice-paid

forj make:event billing:invoice-paid --remove

Removal deletes the generated type, but it does not remove application code that refers to it.

internal/billing/invoice_paid_event.go    created

Events are plain application types, so no Wire or registration file changes.

In existing-file excerpts, highlighted lines are injected by this command.

The generated event converts the grouped name to a dotted stable topic and provides a place for the payload:

internal/billing/invoice_paid_event.go

// InvoicePaidEventTopic is the stable routing key for InvoicePaidEvent.
const InvoicePaidEventTopic = "billing.invoice-paid"

// InvoicePaidEvent is the event payload for InvoicePaidEventTopic.
type InvoicePaidEvent struct {
	// Add event fields.
}

// Topic returns the event bus topic for InvoicePaidEvent.
func (InvoicePaidEvent) Topic() string {
	return InvoicePaidEventTopic
}

make:subscriber

Generate a subscriber for an application event.

forj make:subscriber billing:invoice-paid

Use --bus audit to target a named event bus configured by EVENTS_AUDIT_DRIVER.

forj make:subscriber billing:invoice-paid --remove

Pass the same --bus value used during creation. Removal deletes the generated subscriber, its provider, and its subscription block.

internal/billing/invoice_paid_subscriber.go    created
app/wire/inject_subscribers_app.go             provider and subscription added

In existing-file excerpts, highlighted lines are injected by this command.

The generated subscriber starts with a typed handler:

internal/billing/invoice_paid_subscriber.go

// InvoicePaidSubscriber handles InvoicePaidEvent messages from the configured event bus.
type InvoicePaidSubscriber struct{}

// NewInvoicePaidSubscriber constructs an InvoicePaidEvent subscriber.
func NewInvoicePaidSubscriber() *InvoicePaidSubscriber {
	return &InvoicePaidSubscriber{}
}

// Handle processes InvoicePaidEvent messages.
func (s *InvoicePaidSubscriber) Handle(
	ctx context.Context,
	event InvoicePaidEvent,
) error {
	_ = ctx
	_ = event
	return nil
}

The App Wire file constructs it and performs the subscription:

app/wire/inject_subscribers_app.go

// appSubscriberSet contains application-owned event subscriber providers.
var appSubscriberSet = wire.NewSet(
	ProvideEventSubscribers,
	billing.NewInvoicePaidSubscriber,
)

// ProvideEventSubscribers registers application subscribers with configured event buses.
func ProvideEventSubscribers(
	eventManager *events.Manager,
	billingInvoicePaidSubscriber *billing.InvoicePaidSubscriber,
) (*EventSubscribersReady, error) {
	billingInvoicePaidSubscriberBus := eventManager.Named("default")
	if billingInvoicePaidSubscriberBus == nil {
		return nil, fmt.Errorf("event bus %q is not configured", "default")
	}
	if _, err := billingInvoicePaidSubscriberBus.Subscribe(
		billingInvoicePaidSubscriber.Handle,
	); err != nil {
		return nil, err 
	}
	return &EventSubscribersReady{}, nil
}

make:model

Generate a model and repository helpers in an explicit package.

forj make:model invoices --package billing

The positional argument is the exact name of an existing table. The generator inspects invoices through the default database connection, so that connection must be available. It does not create or migrate the table, and make:model does not select a named connection. The generated Go type and filename are singularized from the inspected table name; when an exact table is missing, the command may suggest an existing singular or plural variant. Models use --package rather than -d because their placement follows database table ownership.

forj make:model invoices --package billing --remove

If the model already exists, the command updates its schema-derived model definition while preserving the repository section.

By default, an ungrouped model is written under ./internal/models. Use --encrypt column_name or --compress column_name to add the corresponding generated field handling; repeat the option or pass comma-separated names for multiple fields.

internal/billing/invoice.go                 created or updated
app/wire/inject_repositories_app.go         repository provider added

Removal deletes the model file, including its repository helpers, and removes the provider.

In existing-file excerpts, highlighted lines are injected by this command.

Model fields reflect the columns discovered in the invoices table. The schema-independent repository portion of the same file starts with:

internal/billing/invoice.go

// InvoiceRepo provides persistence helpers for Invoice.
type InvoiceRepo struct {
	db  *database.Connections
	ctx context.Context
}

// NewInvoiceRepo creates a new Invoice repository.
func NewInvoiceRepo(db *database.Connections) *InvoiceRepo {
	return &InvoiceRepo{db: db}
}

The repository Wire set gains:

app/wire/inject_repositories_app.go

// repositorySet is a wire set for generated repositories.
var repositorySet = wire.NewSet(
	billing.NewInvoiceRepo,
)

make:migration

Generate SQL migration files.

forj make:migration create_invoice_tables

Use --connection for a non-default migration stream. Drivers come from DB_SUPPORTED_DRIVERS, falling back to DB_DRIVER.

forj make:migration create_invoice_tables --remove

Removal deletes timestamped up and down files matching the migration name.

A single-driver App using the default connection creates:

migrations/<timestamp>_create_invoice_tables.up.sql
migrations/<timestamp>_create_invoice_tables.down.sql

Expanded App layouts write under migrations/<app>/<connection>/. Multi-driver Apps add the driver before .up.sql and .down.sql. No Wire files change.

In existing-file excerpts, highlighted lines are injected by this command.

For SQLite, the two starter files contain:

migrations/<timestamp>_create_invoice_tables.up.sql

-- Up migration (sqlite)

migrations/<timestamp>_create_invoice_tables.down.sql

-- Down migration (sqlite)

The timestamp is UTC in YYYY_MM_DD_HHMMSS format. Replace the starter comments with the forward and rollback SQL.

How Package Placement Works

Make commands prefer colocated packages, but command names should stay operationally short.

Use category:action for application command names:

forj make:command reports:sync

This creates internal/reports/sync_cmd.go. Use two segments unless the extra segment is truly part of the operator-facing command. When the command belongs in a deeper package, keep the command name short and use -d to control file placement.

See Naming Conventions for command, job, event, schedule, route, and named resource names.

Bare commands

A bare application command is App-wide:

forj make:command sync

It creates internal/cmd/sync_cmd.go. Use a grouped name when a feature package owns the command:

forj make:command reports:sync

This creates internal/reports/sync_cmd.go and exposes reports:sync. If operator naming and package placement differ, keep the command name short and use -d:

forj make:command reports:sync -d ./internal/ops

The file moves to internal/ops/sync_cmd.go, but the exposed command remains reports:sync.

Go package names

Generated package declarations use compact lowercase Go names. For example:

forj make:controller BillingPortal

This creates a billingportal package, not billing_portal. File names can use underscores, but package names should remain short lowercase identifiers.

Organize by package ownership

Make commands organize code around the package that owns the behavior, not around global controllers, jobs, models, or commands directories.

internal/reports/
  controller.go
  sync_cmd.go
  generate_job.go
  daily_schedule.go
  report_generated_event.go
  report_generated_subscriber.go
  report.go
  service.go

Every .go file in that directory declares package reports, so the package name provides the scope. Controller, SyncCmd, GenerateJob, DailySchedule, Report, and Service are different entry points and collaborators inside one ownership boundary.

Read grouped generator names from left to right:

• forj make:controller reports creates internal/reports/controller.go.
• forj make:job reports:generate creates internal/reports/generate_job.go.
• forj make:schedule reports:daily creates internal/reports/daily_schedule.go.

Controllers are package anchors, so the full grouped name becomes the controller package. For jobs and schedules, the leading segments select the package and the final segment names the generated entry point. Start with a flat package such as internal/reports; add nesting only when another package boundary clarifies ownership.

The generated entry points should stay thin:

HTTP request      -> reports.Controller                -> reports.Service
CLI command       -> reports.SyncCmd                   -> reports.Service
Queue worker      -> reports.GenerateJob               -> reports.Service
Scheduler process -> reports.DailySchedule             -> reports.Service
Event bus         -> reports.ReportGeneratedSubscriber

They translate input, call package services, and return output. Services own workflows and receive repositories, clients, caches, queues, storage, and events through explicit constructor dependencies. Keeping related entry points together makes imports reveal ownership, keeps Wire constructors close to what they construct, and lets a feature move or shrink as one visible unit.

Shared Options

Removing Generated Resources

Removal uses the same name, package, connection, bus, output, and env-file flags as creation. Pass the same options so the generator resolves the same file and registration entries.

Use --dry-run to preview file and wiring cleanup:

forj make:controller reports --remove --dry-run

--remove resolves the conventional generated path and removes the file at that path; it does not distinguish an untouched generated file from one you later edited. It also removes the matching generated registration entries. Migration removal deletes matching timestamped up/down files by migration name.

Commit or preserve application changes before removal, and inspect --dry-run output carefully. Removal does not search for tests, manually added references, or business code elsewhere, so the following build is what exposes remaining dependencies.

After removing a wired resource, rebuild the graph:

forj build

The build exposes application code that still refers to the removed type, route, command, repository, job, schedule, or subscriber.

Opening Generated Files

Source-generating make commands can open their primary generated file after a successful run:

forj make:controller reports -o
forj make:job billing:sync-reports --open

This applies to controllers, commands, events, subscribers, jobs, schedules, models, and migrations. A migration opens its first generated up migration. make:queue only updates configuration, so it has no source file to open.

Use --no-open to suppress opening for one run. Apps can set:

FORJ_MAKE_OPEN=auto
FORJ_EDITOR=

FORJ_MAKE_OPEN accepts:

Value	Behavior
auto	Open only in an interactive terminal when CI is not active.
always	Try to open after every successful generator run.
never	Open only when the command explicitly uses --open or -o.

Automatic opening stays quiet when it cannot resolve an editor. An explicit --open, or FORJ_MAKE_OPEN=always, prints a warning instead.

Set FORJ_EDITOR to pin the command when automatic detection is not what you want:

FORJ_EDITOR="code --reuse-window --goto {location}"
FORJ_EDITOR="goland --line {line} {file}"

The command supports {file} for the absolute generated path, {line} for the line number, and {location} for both as path:line. Without FORJ_EDITOR, GoForj checks terminal editor hints, then running GUI editors, then commands on PATH. Its editor preference is GoLand, Cursor, VS Code, Zed, then IntelliJ IDEA, while preferring an already-running editor over launching a different one.

Output Overrides

Ungrouped resources use these source-owned defaults:

Command	Default output
make:command	./internal/cmd
make:job	./internal/jobs
make:schedule	./internal/schedules
make:event	./internal/events
make:subscriber	./internal/events
make:model	./internal/models

Use -d when the default grouped package path is not the package you want:

forj make:command reports:sync -d ./internal/billing/reports
forj make:job billing:sync-reports -d ./internal/ops
forj make:schedule reports:daily -d ./internal/billing/reports
forj make:event billing:invoice-paid -d ./internal/billing/events
forj make:subscriber billing:invoice-paid -d ./internal/billing/events

The override controls the file location and package name. The grouped command name can still express the command, job, or event identity.

make:model uses --package instead of -d because models and repositories are generated around database table ownership.

Ownership and Verification

What Belongs to You

Generated files are starting points. Your App still owns:

• business logic and service methods
• constructor parameters for application services
• route behavior, validation, and response shape
• command input parsing and console output
• job payloads and handler behavior
• schedule intervals and handler behavior
• event payloads and subscribers
• migration SQL
• model relationships and repository options

Keep dependencies explicit. If a generated controller, command, or job needs an application service, add that service constructor to the right provider set and let Wire pass it in.

Verify

After running a make command, verify the graph and the exposed runtime surface:

forj build
forj route:list

Use route:list for controllers. For commands, run the generated command signature through forj <command>. Use forj run <command> only when you want to force App command execution explicitly.

Common Mistakes

Common mistakes

• Do not create one package per generated file.
• Do not collect every controller, job, command, and service in one global package.
• Do not make operator-facing command names longer merely to mirror package depth.
• Do not use snake case package names.
• Do not put business workflows directly in generated entry points.
• Do not hand-edit generated wiring before using the make command path.

Next Steps

• Controllers shows the HTTP boundary around services.
• Commands shows App-owned CLI entry points.
• Naming Conventions defines stable operational names.
• Wiring Recipes shows where generated and hand-written providers belong.
• CLI Reference lists project-level commands and App command patterns.