Skip to content

Latest commit

 

History

History
35 lines (25 loc) · 1.63 KB

File metadata and controls

35 lines (25 loc) · 1.63 KB

Contributing

Thanks for considering a contribution.

Workflow

  1. Fork the repository and create a branch from main.
  2. Write a failing test first, then make it pass. Every change is test driven.
  3. Keep the public API stable. Anything in src/ that is not marked @internal is a published contract.
  4. Keep the in-repo docs (README.md and docs/) in sync whenever you change commands, config, or user-facing behaviour. The public docs site lives in a separate repo (albertoarena/laravel-truss-docs, published at trussphp.com) and should be updated there in step.
  5. Run the checks below before opening a pull request.

Checks

composer test        # Pest (PHP)
composer lint        # Laravel Pint, code style
npm test             # Vitest, client-side diagram logic
npx playwright test  # Playwright, browser rendering and interaction

The PHP suite uses an in-memory SQLite database and Orchestra Testbench, so no external services are needed.

Conventions

  • Strict types in every PHP file.
  • The introspection layer (src/Introspection/) has zero knowledge of HTTP, Blade, caching, or Mermaid. It takes a connection in and returns a schema representation out.
  • Structure only. Truss never reads or exposes row data. Treat this as a hard constraint.
  • One behaviour per test, with descriptive names.
  • Commit messages as type: short subject, then a body explaining what and why.
  • Do not use em dashes in prose.

Reporting bugs

Open an issue with a minimal reproduction. A failing test is the most helpful form a report can take. For security issues, please email hello@albertoarena.it instead of opening a public issue.