Static analysis: ESLint, PHPStan, mypy — Monitoring & Observability — Practical Guide (Jul 27, 2026)

Static analysis: ESLint, PHPStan, mypy — Monitoring & Observability

Level: Intermediate

As of July 27, 2026, static analysis is a cornerstone of modern software quality assurance. Tools like ESLint, PHPStan, and mypy enable developers to catch bugs early, enforce coding standards, and improve maintainability. Coupling these tools with robust monitoring and observability practices ensures your codebase remains healthy and performant over time.

Prerequisites

Before integrating static analysis tools effectively, ensure:

Familiarity with the programming languages involved: JavaScript/TypeScript (ESLint), PHP (PHPStan), Python (mypy).
Properly configured build or CI pipelines that can run analysis tools automatically.
Basic knowledge of monitoring and observability concepts like metrics collection, alerts, and dashboards.
Node.js environment (ESLint v9.x+), PHP 8.1+ (PHPStan v1.11+), and Python 3.8+ (mypy v1.0+) — confirmed stable major releases as of mid-2026.

Hands-on steps

1. Install and configure ESLint, PHPStan, and mypy

Installation commands and minimal config snippets to get started in typical projects.

# ESLint (JavaScript/TypeScript)
npm install --save-dev eslint
npx eslint --init

{
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  "parser": "@typescript-eslint/parser",
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "single"]
  }
}

# PHPStan (PHP)
composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src --level=max

parameters:
  level: max
  paths:
    - src

# mypy (Python)
pip install mypy
mypy --config-file mypy.ini your_package/

# mypy.ini
[mypy]
python_version = 3.10
strict = True
check_untyped_defs = True
ignore_missing_imports = True

2. Integrate into CI/CD pipelines

Make static analysis a mandatory quality gate to prevent regressions. For example, GitHub Actions workflows:

name: Static Analysis

on: [push, pull_request]

jobs:
  eslint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Run ESLint
        run: npx eslint . --max-warnings=0

  phpstan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install PHP dependencies
        run: composer install --no-interaction
      - name: Run PHPStan
        run: vendor/bin/phpstan analyse --level=max src --no-progress

  mypy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Python dependencies
        run: pip install -r requirements.txt mypy
      - name: Run mypy
        run: mypy --config-file mypy.ini your_package/

3. Monitoring & Observability of Static Analysis

Static analysis metrics should feed into monitoring dashboards with alerting for early detection of quality degradations.

Key metrics: number of errors, warnings, warnings suppressed, code coverage of analysed files, violation trend over time.
Tool outputs: Convert tool outputs into JSON format where possible, e.g. “eslint -f json”, “phpstan -f json”, “mypy –show-error-codes –show-error-context –cache-dir=/dev/null -j 4 –pretty” to aid ingestion.
Ingesting data: Export reports into monitoring systems such as Prometheus, or push to logging/observability platforms like ELK, DataDog, or Grafana Loki.
Dashboards & Alerts: Define thresholds for acceptable error counts. Alerts on trend spikes or increasing suppression rates protect against neglected code quality.

Common pitfalls

Ignoring warnings: Suppressing warnings without triage leads to technical debt. Use suppression sparingly and with justification.
Overly strict levels initially: Aggressive levels like PHPStan level max might overwhelm teams at first; start at medium levels and improve gradually.
Not updating configs: Static analysis tools evolve rapidly. Keep your configs and plugins up to date to benefit from improved diagnostics.
Lack of integration: Running tools only locally reduces impact. Automate runs in CI and integrate with dashboards.
Performance considerations: Static analysis can slow CI. For large codebases, consider incremental runs or staged approaches.

Validation

Validate your setup with these steps:

Run analyses locally and confirm that errors are representative.
Push deliberately bugged code or code with lint violations to verify CI blocks merges.
Check the integration of reports into your monitoring system; verify dashboards update after each run.
Test alerting thresholds by temporarily injecting errors to provoke alerts.
Review suppression comments or config overrides periodically for validity.

Checklist / TL;DR

Install and configure ESLint (v9.x+), PHPStan (v1.11+), and mypy (v1.0+).
Integrate tool execution into CI pipelines, fail builds on errors.
Export static analysis outputs in JSON for ingestion into monitoring systems.
Build dashboards tracking errors, warnings, and suppression trends.
Set alerts on quality regressions to proactively maintain health.
Start with moderate strictness, increase as team matures.
Regularly update configs, handle suppressed warnings responsibly.
Balance performance in CI with incremental analysis where needed.

When to choose ESLint vs PHPStan vs mypy?

These tools serve different ecosystems:

ESLint: Ideal for JavaScript and TypeScript codebases. Focuses both on stylistic issues and some semantic errors. Choose ESLint when working with front-end frameworks or Node.js services.
PHPStan: Provides static analysis specifically for PHP, catching bugs beyond syntax errors. Best suited for modern PHP applications with typed properties and union types (PHP 8.1+).
mypy: Type checking for Python, requiring type annotations. Use when developing medium to large Python projects where static type safety improves reliability.
For mixed-language polyglot projects, combine all relevant tools and unify their observability data.