Skip to content

Latest commit

 

History

History
62 lines (41 loc) · 2.9 KB

File metadata and controls

62 lines (41 loc) · 2.9 KB

Contributing to lathe

Thanks for your interest in lathe. Contributions are licensed under the Apache License 2.0.

Local setup

git clone https://github.com/lathe-cli/lathe.git
cd lathe
make check        # fmt-check, vet, lint, test — the full quality gate

Requires Go (version in go.mod) and golangci-lint. No other tooling needed.

To follow the end-to-end generated CLI workflow, see:

  • CLI Usage for the exact go mod init -> lathe bootstrap -> go build path.
  • examples/petstore, examples/richapi, and examples/graphql for the in-repo generation paths.

Performance

Benchmarks live beside the code they measure as *_bench_test.go and cover the codegen pipeline (spec parsing, normalization) and the generated-CLI runtime (command building, catalog, search, output rendering).

make bench        # go test -bench=. ./...

CI runs the same benchmarks on CodSpeed and reports the performance impact of a pull request against main.

Workflow

  1. Fork the repo, create a feature branch off main.
  2. Keep the change small and focused. Split unrelated work into separate PRs.
  3. Run make check before opening the PR. Add focused tests when they protect a stable behavior or regression boundary.
  4. Sign off every commit with -s: git commit -s -m "...". This attests to the Developer Certificate of Origin (developercertificate.org).
  5. Open a PR describing the problem, the fix, and how you verified it. Link any related issue.

Scope

  • In scope: codegen accuracy, runtime correctness, spec backend improvements (Swagger 2.0, OpenAPI 3, proto, policy-curated GraphQL), application initialization, bundled Skill installation, test coverage, docs, Authenticator / Formatter extensions, overlay ergonomics, cli.yaml schema.
  • Out of scope: new spec formats beyond the supported backends, generic scaffolders, plugin loaders, GUI/TUI. These can ship as sibling projects on top of lathe.

Project conventions

  • Commit messages follow Conventional Commits (feat:, fix:, refactor:, docs:, chore:). Scope is optional.
  • Error wrapping uses fmt.Errorf("...: %w", err); never drop context.
  • Don't commit generated code (internal/generated/) or upstream clones (.cache/).
  • For anything data-driven (auth endpoints, CLI identity, spec sources), prefer extending cli.yaml / specs/sources.yaml over hard-coding.

For system boundaries, package ownership, runtime flow, and capability composition, see docs/architecture.md.

Reporting bugs

Open an issue with a minimal reproduction: the spec (or its shape), the command you ran, and what you expected vs. what happened. Logs from --debug and -o raw are usually more useful than -o table.

Security

See SECURITY.md for vulnerability reporting.