gofasta config

Tools that operate on the project’s configuration surface.

Subcommands

gofasta config schema

Emits a JSON Schema (Draft 7)  describing config.yaml. The schema is generated by reflecting over the AppConfig type in the gofasta library version your project pins — there is no second source of truth to keep in sync.

Usage

gofasta config schema

Examples

Print to stdout:

gofasta config schema

Save to a file for editor consumption:

gofasta config schema > config.schema.json

Inspect one section with jq:

gofasta config schema | jq '.properties.database'

Intended consumers

1. Editor autocomplete + inline validation. Add one line to the top of your config.yaml:

# yaml-language-server: $schema=./config.schema.json

With the VS Code YAML extension (or JetBrains equivalent) installed, you get:

• Autocomplete on field names (type databas and the editor suggests database)
• Red underlines on type errors (putting port: "abc" shows “Expected integer”)
• Required-field warnings in the Problems panel
• Enum hints on fields like database.driver (suggests postgres, mysql, sqlite, sqlserver, clickhouse)

2. CI validation before deploy. Catches typos and wrong types before they hit production:

gofasta config schema > schema.json
ajv validate -s schema.json -d config.yaml

3. AI coding agents editing config.yaml. An agent can fetch the schema to know — from the project’s exact pinned gofasta version — which keys are valid, what their types are, and what values are allowed. Replaces guessing from potentially-stale training data.

How it works

Under the hood, gofasta config schema shells out to a tiny helper binary the scaffold ships at cmd/schema/main.go:

package main
 
import (
    "encoding/json"
    "os"
    "github.com/gofastadev/gofasta/pkg/config"
)
 
func main() {
    enc := json.NewEncoder(os.Stdout)
    enc.SetIndent("", "  ")
    _ = enc.Encode(config.JSONSchema())
}

The helper runs inside your project’s Go module context, so it imports the exact github.com/gofastadev/gofasta/pkg/config version pinned in your go.mod. No version skew between the CLI and the installed library — the schema always matches what your app actually loads.

You can also invoke the helper directly without the CLI:

go run ./cmd/schema > config.schema.json

Output shape

A standard Draft-7 JSON Schema document:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AppConfig",
  "description": "Gofasta application configuration. Loaded from config.yaml and overridden by environment variables prefixed with the project name (e.g. MYAPP_DATABASE_HOST).",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "database": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "driver": { "type": "string" },
        "host": { "type": "string" },
        "port": { "type": "string" },
        "max_idle": { "type": "integer" },
        "max_life": {
          "type": "string",
          "format": "duration",
          "description": "A Go time.Duration expressed as a string (e.g. \"30s\", \"5m\", \"24h\")."
        }
      }
    }
  }
}

Field-tag conventions honored

When the gofasta library adds struct tags to config fields, the emitter translates them:

Related

• Configuration guide — what each config section does
• pkg/config reference — programmatic access
• gofasta do rebuild — regenerate every derived artifact