Thanks for your interest in contributing!
- Fork and clone the repository
- Follow the build instructions to get a working development environment
- Read ARCHITECTURE.md for an overview of how the codebase is structured
All six CI checks must pass with zero warnings and zero failures:
cargo test
cargo clippy -- -D warnings
cargo clippy --tests -- -D warnings
cargo fmt --check
php -l examples/demo.php
php -d zend.assertions=1 examples/demo.php
php -l examples/laravel/app/Demo.php
phpantom_lsp analyze --project-root examples/laravel --no-colourNote that clippy runs twice, once for library code and once including test code. The php -l check ensures examples/demo.php remains valid PHP. The php -d zend.assertions=1 run executes runDemoAssertions() to verify that scaffolding stubs actually return what their docblocks claim. The final php -l and phpantom_lsp analyze runs check examples/laravel/ for syntax errors and diagnostic regressions. The analyze run must report [OK] No errors.
- Run
cargo fmtbefore committing - Fix clippy warnings rather than suppressing them. Avoid
#[allow(clippy::...)]unless truly necessary. - Add
///doc comments to all public functions and struct fields
- Integration tests go in
tests/completion_*.rsortests/definition_*.rs, one file per feature area - Use
create_test_backend()fromtests/common/mod.rsfor same-file tests - Use
create_psr4_workspace()for cross-file / PSR-4 tests - Test the happy path, edge cases, and interactions with existing features
- When adding a feature, update
examples/demo.phpwith working examples (and verify withphp -l examples/demo.php). For Laravel-specific features, also updateexamples/laravel/app/Demo.php(and verify withphp -l examples/laravel/app/Demo.php).
See BUILDING.md for more on running tests and manual LSP testing.
Update CHANGELOG.md when your PR adds, changes, or fixes something a user would notice. Add entries under ## [Unreleased] in the appropriate subsection (### Added, ### Fixed, ### Changed, or ### Removed). Write for end users, not developers: describe what changed in the editor, not which internal modules were touched. See the existing entries for the style and level of detail expected.
The documentation site is built with Zensical. The only dependency you need is uv.
Preview the docs locally with live reload:
uv run zensical serveThen open http://127.0.0.1:8000 in your browser. Changes to files in
docs/ and zensical.toml are reflected immediately. If port 8000 is
already in use, pick a different one:
uv run zensical serve -a 127.0.0.1:8200Build the docs for offline use:
uv run zensical buildThe output is written to site/ (gitignored). uv handles creating
a virtual environment and installing all Python dependencies
automatically on first run.
Open an issue on GitHub with:
- What you expected to happen
- What actually happened
- Steps to reproduce (a minimal PHP snippet is ideal)