View Source Contributing

Thanks for looking at Dynamo. Bug reports, questions and pull requests are welcome.

Before you open a pull request

  • Open an issue first for anything that changes the public API or adds a DynamoDB feature, so the shape can be agreed before code is written.
  • Read Agents.md for the mental model and skills/dynamo-maintainer/SKILL.md for the invariants, the test tiers and the step-by-step procedure for adding a feature. The maintainer skill is written for AI agents and applies to humans just the same.

Running the checks 

mix deps.get
mix format --check-formatted
MIX_ENV=test mix compile --force --warnings-as-errors
mix test
mix docs

All four must be clean. The unit suite runs against an in-memory fake (test/support/fake_dynamo.ex) and takes about a second.

Changes that touch the wire (new request, new attribute type, endpoint routing) also need a scenario in test/integration/live_test.exs. It runs against DynamoDB Local or a real AWS account and cleans up its own tables:

DYNAMO_ENDPOINT=http://localhost:8000 AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
  mix test --include integration test/integration/live_test.exs

What a good pull request looks like

  • One change per PR, with a test that fails without it.
  • Request builders get a golden-payload test; schema DSL changes get a compile-error test for the failure case.
  • Documentation updated in the same PR: README section, Agents.md cheat sheet, the relevant guide, and a CHANGELOG.md line under "unreleased". Every snippet in the docs must run.
  • No new dependencies without discussion. Runtime deps are req and jason; decimal is optional and must stay optional.

Style

mix format decides. Beyond that: public functions return {:ok, value} | {:error, %Dynamo.Error{}}, options are validated with Keyword.validate/2, invalid input is an error and never a sentinel value.

Reporting a security issue

See SECURITY.md. Please don't open a public issue for it.