Laravel Pint

Ein Code-Style-Fixer auf Basis von PHP CS Fixer. Wie Sie im Team einen einheitlichen Coding-Style sicherstellen.

​

Was ist Laravel Pint

Laravel Pint ist ein automatischer Code-Style-Fixer, der auf PHP CS Fixer aufsetzt. Er ist so konzipiert, dass er ohne Konfiguration sofort einsatzbereit ist, und richtet den Code automatisch nach dem Laravel-Stil aus.

Wenn Sie die im Team üblichen „Codestyle-Kommentare“ automatisieren, können Sie sich in Reviews auf das Wesentliche konzentrieren.

​

Installation

In neu erstellten Laravel-Anwendungen ist Pint bereits installiert. In älteren Projekten installieren Sie es mit Composer.

composer require laravel/pint --dev

​

Ausführung

​

Grundlegende Nutzung

Alle .php-Dateien im Projekt automatisch anpassen:

./vendor/bin/pint

Sie können den Aufruf auch auf bestimmte Dateien oder Verzeichnisse begrenzen.

./vendor/bin/pint app/Models
./vendor/bin/pint app/Models/User.php

​

Optionen

Option	Beschreibung
--test	Nur prüfen, ohne Dateien zu ändern. Bei Fehlern wird ein Non-Zero-Exit-Code zurückgegeben
--dirty	Nur Dateien mit ungecommitteten Änderungen (Git) prüfen
--diff=[branch]	Nur Dateien prüfen, die sich vom angegebenen Branch unterscheiden
--repair	Style-Fehler korrigieren und bei Änderungen einen Non-Zero-Exit-Code zurückgeben
--parallel	Paralleler Modus (experimentell) für mehr Performance
--max-processes=4	Kombiniert mit --parallel die maximale Prozesszahl festlegen
-v	Details der Änderungen anzeigen
--config	Pfad zur zu verwendenden pint.json angeben
--preset	Zu verwendendes Preset angeben

# Nur prüfen, keine Änderungen
./vendor/bin/pint --test

# Nur nicht committete Dateien
./vendor/bin/pint --dirty

# Parallel ausführen
./vendor/bin/pint --parallel

​

Konfiguration

Legen Sie im Projekt-Root eine pint.json an, um das Verhalten anzupassen.

{
    "preset": "laravel"
}

Alternativ geben Sie den Pfad zur Konfigurationsdatei explizit an.

./vendor/bin/pint --config vendor/my-company/coding-style/pint.json

​

Presets

Presets sind vordefinierte Regel-Sets. Standard ist laravel – die für Laravel-Projekte optimalen Regeln.

Preset	Beschreibung
laravel	Empfohlener Laravel-Stil (Standard)
psr12	PSR-12-Coding-Standard
per	PER Coding Style
symfony	Symfony-Coding-Style
empty	Keine Regeln. Regeln einzeln definieren

# Preset auf der Kommandozeile setzen
./vendor/bin/pint --preset psr12

​

Regeln anpassen

In pint.json aktivieren oder deaktivieren Sie einzelne Regeln. Verfügbare Regeln finden Sie im PHP CS Fixer Configurator.

{
    "preset": "laravel",
    "rules": {
        "simplified_null_return": true,
        "array_indentation": false,
        "new_with_parentheses": {
            "anonymous_class": true,
            "named_class": true
        }
    }
}

​

Dateien und Ordner ausschließen

Bestimmte Ordner lassen sich ausschließen.

{
    "exclude": [
        "my-specific/folder"
    ]
}

Für Ausschlüsse per Dateiname-Pattern verwenden Sie notName.

{
    "notName": [
        "*-my-file.php"
    ]
}

Für einen konkreten Dateipfad notPath.

{
    "notPath": [
        "path/to/excluded-file.php"
    ]
}

​

Empfohlene Konfiguration

Ein Beispiel für eine praxistaugliche pint.json:

{
    "preset": "laravel",
    "rules": {
        "no_unused_imports": false,
        "strict_comparison": true,
        "declare_strict_types": true
    }
}

Warum die einzelnen Regeln:

Regel	Wirkung
no_unused_imports	Auf false gesetzt, werden ungenutzte use-Anweisungen nicht entfernt. Standard von Pint ist true (Entfernen), daher ist der Eintrag in normalen Laravel-Projekten nicht nötig
strict_comparison	Wandelt == in === und != in !== um und verhindert Bugs durch unerwartete Typumwandlungen
declare_strict_types	Fügt automatisch declare(strict_types=1); am Dateianfang ein und verbessert die Typsicherheit

strict_comparison und declare_strict_types erzwingen strikt typisierten Code. In bestehenden Projekten kann der Erstlauf viele Änderungen erzeugen. In neuen Projekten empfiehlt sich der Einsatz von Anfang an.

no_unused_imports ist vor allem für Paketentwicklung gedacht. Pints Standard ist true (ungenutzte use-Anweisungen entfernen); im normalen Laravel-Projekt ist der Eintrag daher nicht nötig. In der Paketentwicklung schaltet man Funktionalität oft über den Import von Traits oder Interfaces ein/aus. Deshalb ist es praktisch, den Wert auf false zu setzen und pro Paket bei Bedarf auf true zu ändern.

​

Scripts in der composer.json

Wenn Sie in der composer.json Skripte für Pint registrieren, reicht composer pint.

{
    "scripts": {
        "pint": "./vendor/bin/pint",
        "pint:test": "./vendor/bin/pint --test"
    }
}

Anschließend führen Sie aus:

# Code automatisch korrigieren
composer pint

# Nur prüfen (ohne Änderungen)
composer pint:test

In CI-Umgebungen erkennen Sie mit composer pint:test Style-Verstöße, ohne Dateien zu ändern. Die Option --test gibt bei Fehlern einen Non-Zero-Exit-Code zurück und eignet sich damit für Pass/Fail-Checks in der CI.

​

Automatische Ausführung mit GitHub Actions

Mit GitHub Actions können Sie bei jedem Push automatisch den Code-Style korrigieren und committen.

1. Workflow-Berechtigungen einstellen

   Aktivieren Sie in Ihrem GitHub-Repository unter Settings > Actions > General > Workflow permissions die Option „Read and write permissions“.

2. Workflow-Datei erstellen

   Legen Sie .github/workflows/lint.yml an.

   name: Fix Code Style
   
   on: [push]
   
   jobs:
     lint:
       runs-on: ubuntu-latest
       strategy:
         fail-fast: true
         matrix:
           php: [8.4]
   
       steps:
         - name: Checkout code
           uses: actions/checkout@v5
   
         - name: Setup PHP
           uses: shivammathur/setup-php@v2
           with:
             php-version: ${{ matrix.php }}
             tools: pint
   
         - name: Run Pint
           run: pint
   
         - name: Commit linted files
           uses: stefanzweifel/git-auto-commit-action@v6
   

Dieser Workflow führt bei jedem Push Pint aus und committet die formatierten Dateien automatisch.

Da Style-Anpassungen vor dem Review erfolgen, sinken die Codestyle-Kommentare in Pull Requests. Bei der Einführung im Team empfiehlt es sich, zunächst alle Dateien lokal zu korrigieren und den Workflow danach hinzuzufügen, um Zusatz-Commits zu vermeiden.