Thanks for considering a contribution.
- Fork the repository and create a branch from
main. - Write a failing test first, then make it pass. Every change is test driven.
- Keep the public API stable. Anything in
src/that is not marked@internalis a published contract. - Keep the in-repo docs (
README.mdanddocs/) 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. - Run the checks below before opening a pull request.
composer test # Pest (PHP)
composer lint # Laravel Pint, code style
npm test # Vitest, client-side diagram logic
npx playwright test # Playwright, browser rendering and interactionThe PHP suite uses an in-memory SQLite database and Orchestra Testbench, so no external services are needed.
- 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.
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.