README

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:

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/denzyldick/phanalist/main/bin/init.sh | sh

It will automatically download the executable for your platform:

$ ~/phanalist -V
phanalist 1.0.0

There are also multiple other installation options.

GitHub Action

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

name: Phanalist
on: [pull_request]
permissions:
  security-events: write
jobs:
  phanalist:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denzyldick/phanalist-action@v1

Usage

To analyze your project sources, run:

~/phanalist

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:

# Who has violations in their code currently
~/phanalist --blame

# See what changed in the last 30 days (Net column shows who is improving vs degrading)
~/phanalist --blame --since "30 days"

# See changes over the last year
~/phanalist --blame --since "1 year"

# Exclude bots
~/phanalist --blame --since "30 days" --exclude-author dependabot

# Sort by net improvements (who is adding the most value)
~/phanalist --blame --since "30 days" --sort net

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:

~/phanalist --use-baseline phanalist-baseline.json --update-baseline

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

~/phanalist --use-baseline phanalist-baseline.json

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: []   # empty = all rules active
disable_rules: []
exclude_paths: []   # paths skipped before any rule runs (see below)
rules:
  E0007:
    check_constructor: true
    max_parameters: 5
  E0009:
    max_complexity: 10
  E0010:
    max_paths: 200
  E0012:
    include_namespaces:
      - "App\\Service\\"
      - "App\\Controller\\"
    exclude_namespaces: []
    reset_interfaces:
      - "ResetInterface"
  E0015:
    threshold: 1
  E0016:
    max_complexity: 15
  E0024:
    max_loc: 30
  E0025:
    max_loc: 500
  E0026:
    min_ratio: 0.1
    max_ratio: 0.5
  E0027:
    max_methods: 15
    max_fields: 10
  E0028:
    max_getter_setter_ratio: 0.7
    min_methods: 3
  E0029:
    max_fan_out: 10
    max_fan_in: 20
  E0030:
    max_density: 0.3

• 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.

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:

phanalist --lsp

Editor Configuration Examples

Neovim (using vim.lsp)

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

vim.api.nvim_create_autocmd("FileType", {
  pattern = "php",
  callback = function()
    local root_dir = vim.fs.dirname(vim.fs.find({'phanalist.yaml', '.git'}, { upward = true })[1])
    if root_dir then
      vim.lsp.start({
        name = "phanalist-lsp",
        cmd = { "phanalist", "--lsp" },
        root_dir = root_dir,
      })
    end
  end,
})

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