Download the PHP package denzyl/phanalist without Composer

Performant static analyzer for PHP, written in Rust. Catches common mistakes and enforces best practices with zero configuration required.

🤔 Why Phanalist?

PHP codebases grow. As they grow, they accumulate technical debt — god classes that do everything, methods no one can follow, hidden complexity that breaks with every change. Traditional linters catch syntax errors and style issues, but they don't tell you if your code is maintainable.

Phanalist focuses on structural health. It measures what matters for long-term maintainability:

• Complexity metrics — cyclomatic complexity, cognitive complexity, LOC per method, nested paths
• Coupling & cohesion — Law of Demeter violations, god classes, data classes, fan-in/fan-out
• Object-oriented design — depth of inheritance, weighted methods per class, response for a class
• Readability — comment ratios, error suppression, method parameter counts

Think of it as a health checkup for your PHP code. It doesn't just tell you that something is wrong — each rule explains why it matters and how to fix it.

✨ Features

• 🚀 Fast — built in Rust, analyzes large codebases in seconds
• 🔍 31 built-in rules — covering complexity, style, design patterns, and more
• ⚙️ Zero config to start — works out of the box, configure only what you need
• 📄 Multiple output formats — text, json, sarif (for CI pipelines with inline PR annotations via GitHub Action), and codeclimate (for Code Quality platforms)
• 🔌 Extensible — adding a custom rule takes minutes

Installation

The simplest way to install Phanalist is to use the installation script:

It will automatically download the executable for your platform:

There are also multiple other installation options.

GitHub Action

Add inline SARIF annotations to your PRs using the Phanalist GitHub Action:

Usage

To analyze your project sources, run:

Example

On the first run phanalist.yaml will be created with the default configuration and reused on all subsequent runs.

Additional CLI flags:

Engineer Quality Report

Use the --blame flag to see who is introducing and fixing violations in your codebase:

The report shows a table with:

Sorting:

Use --sort to change the order: total (default, by volume), net (by net improvements), name, fixed, introduced.

How it works:

• Without --since: Looks at the current violations in your code and uses git blame to figure out who last touched each affected line. Engineers are credited with the violations in code they most recently worked on.
• With --since <date>: Takes a snapshot of your code as it was at that date, runs the same analysis on the old version, and compares the results. Violations that disappeared were "fixed" — violations that appeared were "introduced". Each change is attributed to the engineer who made it.

Output:

The report includes a summary table and a per-rule breakdown with colored counts (green for fixed, red for introduced).

The --blame flag works with --output-format json — the engineer data is included as an "engineer_report" field in the JSON output for use in pipelines or dashboards.

Requires a .git directory (discovered from the current working directory). Only files within --src paths are attributed.

Baseline

A baseline lets you adopt phanalist on an existing codebase without fixing every finding at once. It freezes the current violations; later runs report only new ones, so CI stays green on known debt but fails on regressions.

Generate (or regenerate) the baseline:

Then run against it (in CI, or locally):

The baseline is a pretty-printed, stably sorted JSON file, so it produces clean diffs and merges. Each entry is keyed on the file, rule, and a stable message id with a count, so unrelated edits that shift line numbers do not invalidate it, and reworded message text does not either. When you fix violations, regenerate the baseline to shrink it.

Configuration

• enabled_rules — whitelist of rules to run (empty = all)
• disable_rules — rules to skip
• rules — per-rule configuration options
• exclude_paths — files skipped before any rule runs, as directory prefixes (var/cache, bootstrap/cache) or globs (**/*.generated.php). Handy for framework caches and frozen code like migrations that would only add noise. Literal (non-glob) patterns that don't exist on disk trigger a warning at -v verbosity — a helpful catch for typos. Globs that match nothing are silently accepted.

Scanning a whole project

Pointing --src . at a project root works and stays memory-safe: each file's parse tree is released before the next one is read, so peak memory tracks the largest single file rather than the size of the tree.

Two things do still scale with the run: the violations you asked to report, and the time spent parsing. Excluding dependencies and generated code with exclude_paths is the cheapest way to cut both:

Rules

Adding a new rule is straightforward — this tutorial explains how.

🔌 Language Server Protocol (LSP)

Phanalist includes built-in LSP support to provide real-time, as-you-type diagnostics directly in your editor.

To start the language server, run:

Editor Configuration Examples

Neovim (using vim.lsp)

Add the following to your init.lua or filetype plugin (ftplugin/php.lua):

VS Code

You can use any generic LSP extension or configure your settings to run phanalist --lsp as a language client for PHP files.

Articles

Read a series of chapters on https://dev.to/denzyldick to understand the project's internals — a great, easy-to-read introduction.

1. Write your own static analyzer for PHP.
2. How I made it impossible to write spaghetti code.
3. Detecting spaghetti code in AST of a PHP source code.
4. Getting Symfony app ready for Swoole, RoadRunner, and FrankenPHP (no AI involved).
5. Improve your CI output
6. Why using unserialize in PHP is a bad idea