Extract code generation logic into internal/api package

[kyleconroy]

Introduce internal/api, a small programmatic interface to sqlc's code generation, inspired by esbuild's Build API. One entry point, api.Generate(ctx, api.GenerateOptions{}), returns a GenerateResult. The CLI becomes a thin wrapper.

Public surface

The package exports exactly three names:

func Generate(ctx context.Context, opts GenerateOptions) GenerateResult

type GenerateOptions struct {
    Config               io.Reader // sqlc YAML/JSON config; required
    Stderr               io.Writer
    Write                bool      // write generated files to disk
    Diff                 bool      // diff generated files against on-disk
    BaseDir              string    // resolves relative paths in Config; strips prefix in stderr labels
    EnableProcessPlugins bool      // permit process-based plugins to run
}

type GenerateResult struct {
    Files  map[string]string
    Errors []error
}

Everything else in the package — parse, codegen, the plugin shim, the result processor — is unexported.

Notable design choices

• Config as io.Reader. No Dir/File fields. Callers hand sqlc whatever bytes they want. The CLI reads from disk; library callers can construct configs in memory.
• BaseDir does double duty. It's the directory relative paths in the config resolve against and the prefix stripped from file paths in parse errors and diff labels. When empty it defaults to the current working directory. Six fields total, no separate "dir for resolving" vs. "dir for labels."
• Process plugins are off by default. EnableProcessPlugins is a single bool whose zero value refuses any process plugin in the config — process plugins execute arbitrary local commands, so callers must opt in. The CLI sets it from env.Debug.ProcessPlugins, which defaults to true and flips off under SQLCDEBUG=processplugins=0.
• Write/Diff replace separate functions. sqlc generate is api.Generate{Write: true}, sqlc compile is neither, sqlc diff is {Diff: true}. cmd.Diff is gone.

CLI

internal/cmd/cmd.go's genCmd, checkCmd, and diffCmd each:

1. Read the config bytes.
2. os.Chdir into the config's directory so relative paths resolve.
3. Call api.Generate with Config: bytes.NewReader(data), BaseDir: configDir, and EnableProcessPlugins: env.Debug.ProcessPlugins.

cmd.Vet and cmd.Push still use the cmd-local helpers (parse, processQuerySets, codeGenRequest) since they have surface beyond what api covers; both packages skip joining their dir parameter when the path is already absolute, so configs with absolute paths flow through both.

Endtoend tests

internal/endtoend/endtoend_test.go calls api.Generate directly. A small mutatedConfigBytes helper parses the test's config, optionally applies a mutation (the managed-db context adds servers + sets database.managed), forces version "2" so v1 configs round-trip cleanly, and re-encodes as YAML. When mutated, the bytes are also dropped to a temp file alongside the original so cmd.Vet (which still takes a path) can use it.

Per-test environment variables from exec.json are applied via t.Setenv, and cmd.Env is then populated via opts.DebugFromEnv/ExperimentFromEnv — same path the CLI takes.

config.AnalyzerDatabase gained MarshalYAML/MarshalJSON so the parsed Config round-trips through yaml.Marshal cleanly — needed for the test helper.

Files

• New: internal/api/{api,generate,process,parse,codegen,shim,diff}.go
• Modified: internal/cmd/{cmd,generate,vet,process}.go, internal/config/config.go, internal/endtoend/endtoend_test.go, internal/endtoend/vet_test.go
• Removed: internal/cmd/diff.go

Test plan

• go test ./internal/endtoend/... (TestExamples, TestReplay base + managed-db) passes locally
• go test ./... passes outside of pre-existing MySQL infra failures (TestExpandMySQL, TestValidSchema/*/mysql/*, TestExamplesVet/{authors,booktest,ondeck})
• go build ./... and go vet ./... clean