PhpStorm Settings für große Monorepos und Enterprise-Projekte

1. Das Problem mit großen Projekten in PhpStorm

PhpStorm mit Standardkonfiguration auf einem Magento-Projekt mit 300 Modulen zu öffnen führt zu einem bekannten Ergebnis: Die IDE indiziert Stunden, der Lüfter des Laptops läuft auf Volllast, Autocompletion reagiert träge, und Inspektionen markieren tausende Warnungen in vendor/-Code, den niemand ändern will. Das ist kein Fehler von PhpStorm – es ist eine Folge von Standard-Einstellungen, die für kleine Projekte ausreichen, für Enterprise-Setups aber angepasst werden müssen.

Das Kernproblem ist das Indexing: PhpStorm analysiert standardmäßig alles, was im Projektverzeichnis liegt. Bei Magento bedeutet das: vendor/ mit tausenden PHP-Dateien, generated/ mit automatisch erzeugtem Code, pub/static/ mit kompilierten Assets, var/ mit Laufzeitdaten. Diese Verzeichnisse brauchen keine vollständige IDE-Analyse – sie müssen im Autocompletion-Index sein, aber nicht als bearbeitbare Quelldateien behandelt werden. Der Unterschied zwischen "excluded" und "library root" ist dabei entscheidend.

Ein zweites Problem betrifft Monorepos mit mehreren eigenständigen Anwendungen: PhpStorm hat ein einzelnes Project-Konzept und behandelt das gesamte Verzeichnis als eine PHP-Anwendung. In einem Monorepo mit einem Magento-Backend, einem Node.js-Frontend und einem Python-Skript-Ordner kann das zu inkonsistenter Autocompletion und verwirrender Fehleranzeige führen. Hier helfen Scopes und Content-Root-Konfigurationen.

2. Indexing-Excludes: was PhpStorm nicht analysieren soll

Indexing-Excludes sind die wichtigste Performance-Maßnahme für große PHP-Projekte in PhpStorm. Man unterscheidet zwischen zwei Kategorien: Verzeichnisse, die komplett aus der Analyse herausgenommen werden sollen (Excluded), und Verzeichnisse, die als Library behandelt werden sollen (im Index für Autocompletion, aber keine Inspektionen). Für Magento empfiehlt sich folgende Aufteilung:

Excluded: pub/static/, var/, dev/, .git/, Node-Module-Verzeichnisse. Diese Verzeichnisse enthalten keine PHP-Klassen, die man in Autocompletion braucht. Library Root: vendor/, generated/. Diese braucht PhpStorm für Autocompletion, soll aber keine Inspektionen oder Warnungen darin anzeigen. Die Konfiguration erfolgt in den Project Structure Settings (Settings → Project → Project Structure) oder über die .idea/-Konfigurationsdateien.

# .idea/Mironsoft.iml — Project Structure Konfiguration
# (wird automatisch von PhpStorm verwaltet, hier zur Dokumentation)

# Verzeichnisse als EXCLUDED markieren (kein Index, keine Inspektionen):
# - src/pub/static     (kompilierte Assets)
# - src/var            (Cache, Logs, Sessions)
# - src/dev            (Dev-Tools, keine Quelldateien)

# Verzeichnisse als SOURCE ROOT markieren:
# - src/app/code       (eigener Code — vollständige Analyse)
# - src/app/design     (Templates — vollständige Analyse)

# Verzeichnisse als LIBRARY ROOT markieren:
# - src/vendor         (Autocompletion, keine Inspektionen)
# - src/generated      (Autocompletion für DI-Proxies)

# PhpStorm .gitignore-Empfehlung für .idea/:
# .idea/workspace.xml   (persönliche Einstellungen — nicht committen)
# .idea/shelf/          (temporäre Änderungen — nicht committen)
# .idea/*.iml           (projekt-spezifisch — committen!)
# .idea/runConfigurations/ (Run Configs — committen!)

Eine häufige Quelle von Performance-Problemen: PhpStorm indiziert vendor/ vollständig als Quelldateien. In einem Magento-Projekt mit einem vendor/-Ordner von 500 MB und tausenden PHP-Klassen dauert dieser Index-Aufbau lange und verbraucht viel Heap. Die Lösung ist, vendor/ als "Library Root" zu markieren, nicht als Quelldateien. Dann hat man Autocompletion, aber keine Inspektionen und keinen unnötigen Index-Overhead.

3. Heap und JVM-Einstellungen für große Codebasen

PhpStorm läuft auf der JVM und hat einen Standard-Heap von 2 GB. Für Enterprise-Projekte mit Magento und vielen Modulen ist das häufig zu wenig. Symptome: PhpStorm wird träge nach mehreren Stunden Arbeit, Garbage-Collection-Pausen werden spürbar, der Indexing-Prozess dauert sehr lange. Die Lösung: den Heap unter Help → Change Memory Settings auf 4 GB oder mehr erhöhen. Bei 16 GB RAM sind 4–6 GB für PhpStorm sinnvoll.

Zusätzliche JVM-Optionen können in der phpstorm64.vmoptions-Datei konfiguriert werden, die man über Help → Edit Custom VM Options öffnet. Wichtige Einstellungen für große Projekte: -Xms2g (initiale Heap-Größe, reduziert Aufwärm-Zeit), GC-Algorithmus (-XX:+UseG1GC ist der Standard und gut für IDE-Workloads), und der Dateisystem-Notifier-Limit unter Linux (inotify-Limit muss erhöht werden).

# phpstorm64.vmoptions — optimiert für Enterprise-Projekte
# Öffnen über: Help → Edit Custom VM Options

# Heap: mindestens 4GB für Magento-Monorepos
-Xms2g
-Xmx6g

# G1 Garbage Collector — Standard ab JVM 9, gut für IDE-Workloads
-XX:+UseG1GC
-XX:SoftRefLRUPolicyMSPerMB=50
-XX:ReservedCodeCacheSize=512m
-XX:+HeapDumpOnOutOfMemoryError

# Dateisystem-Performance unter Linux
# Voraussetzung: sudo sysctl fs.inotify.max_user_watches=524288
# Dauerhaft: echo "fs.inotify.max_user_watches=524288" | sudo tee /etc/sysctl.d/99-phpstorm.conf

# Startup-Optimierung
-XX:CICompilerCount=2
-XX:+TieredCompilation

# IDE-Performance
-Dsun.io.useCanonCaches=false
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djdk.attach.allowAttachSelf=true

# Verify-Fehler bei bestimmten JVM-Versionen unterdrücken
-XX:-OmitStackTraceInFastThrow

Unter Linux gibt es einen häufigen Fallstrick: das inotify-Limit des Betriebssystems. PhpStorm beobachtet Dateiänderungen über inotify und braucht für jedes Verzeichnis einen Watch. Große Projekte überschreiten schnell das Standard-Limit von 8192 Watches. Das Symptom: PhpStorm meldet "External file changes sync may be slow" und aktualisiert geänderte Dateien nicht zuverlässig. Die Lösung: sudo sysctl fs.inotify.max_user_watches=524288, dauerhaft in /etc/sysctl.d/ eintragen.

4. Scopes: Suche und Inspektionen auf relevante Bereiche beschränken

Scopes in PhpStorm definieren Dateigruppen, die für bestimmte Operationen verwendet werden. Mit Scopes kann man die IDE-weite Suche (Find in Files), Inspektionen und Code-Analyse auf die Verzeichnisse beschränken, die für die aktuelle Aufgabe relevant sind. In einem Magento-Monorepo mit eigenem Code in app/code/Mironsoft/ und Template-Dateien in app/design/ definiert man einen Scope "Mironsoft-Code", der nur diese Pfade enthält.

Scope-Definitionen sind einfache Pattern-Ausdrücke: file:src/app/code/Mironsoft//* für alle Dateien unter dem Mironsoft-Namespace. Scopes werden unter Settings → Scopes angelegt und können dann bei Inspektionen (Code → Inspect Code → Custom Scope), bei der Suche (Scope-Dropdown in Find in Files) und bei Refactoring-Operationen verwendet werden. So läuft eine Inspektion nur auf eigenem Code, nicht auf tausenden vendor-Dateien.

5. Inspection-Profile für Enterprise-Projekte konfigurieren

Das Standard-Inspection-Profil von PhpStorm zeigt in großen PHP-Projekten schnell hunderte Warnungen, von denen viele nicht relevant oder in Libraries nicht behebbar sind. Die Lösung ist ein projektspezifisches Inspection-Profil, das unter Settings → Editor → Inspections angelegt und auf einen Scope beschränkt wird. Ein sinnvolles Profil für Magento-Projekte enthält: alle PHP-Typ- und Logik-Inspektionen aktiviert für app/code/-Scope, PHPCS-Inspektionen nur für eigenen Code, und deaktivierte Duplikats- und Dead-Code-Warnungen für Libraries.

Inspection-Profile können als XML exportiert und ins Repository committed werden. Das stellt sicher, dass alle Entwickler im Team dieselben Warnungen sehen und dieselben Probleme als relevant eingestuft werden. In .idea/inspectionProfiles/ liegt das Profil als XML-Datei, die zusammen mit anderen .idea/-Konfigurationen ins Git-Repository gehört.

6. Settings Sync und Team-Konsistenz

In Enterprise-Teams mit mehreren Entwicklern ist die Konsistenz der PhpStorm-Einstellungen ein echtes Problem. Jeder Entwickler hat leicht andere Einstellungen, was zu unterschiedlichem Verhalten bei Inspektionen, Code-Style und Refactoring führt. PhpStorm bietet zwei Wege für Team-Konsistenz: Settings Sync über JetBrains Account (synchronisiert persönliche Einstellungen) und das Einchecken von .idea/-Dateien ins Repository (synchronisiert projektspezifische Einstellungen).

Für Enterprise-Projekte empfiehlt sich eine klare Aufteilung: Persönliche Einstellungen (Keymap, UI-Präferenzen, Themes) über Settings Sync pro Entwickler. Projektspezifische Einstellungen (Code-Style, Inspektions-Profile, Run Configurations, Scopes) über .idea/-Dateien im Repository. Eine .gitignore in .idea/ definiert, welche Dateien geteilt werden und welche lokal bleiben.

# .idea/.gitignore — was committen, was nicht

# NICHT committen (persönlich/lokale Pfade):
workspace.xml
tasks.xml
dictionaries/
shelf/
*.iws
httpRequests/

# COMMITTEN (team-relevant):
# - inspectionProfiles/*.xml
# - runConfigurations/*.xml
# - codeStyles/
# - scopes/
# - *.iml
# - modules.xml
# - vcs.xml
# - sqldialects.xml

# Beispiel: Code Style XML für PHP
# .idea/codeStyles/Project.xml
# → PSR-12-Basis mit Projektspezifika
# → Wird von PhpStorm automatisch geladen
# → Formatierung mit Strg+Alt+L nutzt diese Settings

# Beispiel: Shared Run Configuration
# .idea/runConfigurations/Deploy_Dev.xml
# → Shell-Skript: bin/deploy-dev
# → Alle Entwickler haben denselben Deploy-Task

7. Monorepo-spezifische Konfigurationen

Monorepos mit mehreren Anwendungen in einem Repository erfordern besondere PhpStorm-Konfiguration. PhpStorm kennt kein natives "Monorepo-Konzept", aber man kann es mit mehreren Content Roots simulieren: Jedes Subprojekt kann als eigener Content Root hinzugefügt werden (Settings → Project → Project Structure → Add Content Root). Damit bekommt jedes Subprojekt seinen eigenen Source-Root und eigene Exclude-Regeln.

In einem Monorepo mit backend/ (Magento), frontend/ (Node.js) und shared/ (gemeinsame Konfiguration) wäre die sinnvolle Konfiguration: backend/src/app/code als PHP-Source-Root, backend/src/vendor als Library Root, frontend/ als JavaScript-Content-Root mit eigenen Einstellungen, shared/ als einfacher Ordner ohne spezielle Rolle. PhpStorm behandelt dann PHP-Autocomplete und JavaScript-Autocomplete kontextsensitiv in den jeweiligen Bereichen.

8. Plugins in großen Projekten sinnvoll einsetzen

Jedes aktivierte Plugin erhöht den Speicherbedarf und verlängert den IDE-Start. In Enterprise-Projekten ist die Plugin-Liste konsequent auf das Notwendige zu reduzieren. Nicht benötigte Plugins unter Settings → Plugins deaktivieren – PhpStorm kommt mit vielen vorinstallierten Plugins, von denen in einem reinen PHP-Backend-Projekt viele nicht benötigt werden: Spring, Go, Kubernetes, Angular, Vue etc. können deaktiviert werden, wenn das Projekt sie nicht verwendet.

Für Magento-Enterprise-Projekte empfehlenswerte Plugins: Magento PhpStorm (offizielle JetBrains-Unterstützung für Magento-di.xml und layout.xml), .env Files Support, PHP Annotations, Database Tools (nativ in Ultimate). Zu meidende Plugins in großen Projekten: allgemeine "Productivity"-Plugins die viele Dateien scannen, AI-Plugins die bei jedem Tastendruck API-Aufrufe machen wenn keine stabile Verbindung vorhanden ist, und mehrere Git-Plugins die dieselbe Funktionalität duplizieren.

9. Vergleich: Standard-Konfiguration vs. Enterprise-Konfiguration

Der Unterschied zwischen einer Standard- und einer Enterprise-Konfiguration von PhpStorm ist in der Praxis erheblich. Die folgende Tabelle zeigt die wichtigsten Punkte und was sich konkret ändert.

Die Konfigurationsarbeit für eine Enterprise-PhpStorm-Einrichtung ist einmalig, zahlt sich aber täglich aus. Ein Team von zehn Entwicklern, das täglich 30 Minuten durch langsame IDE-Performance verliert, summiert das auf 5 Stunden pro Tag an verschwendeter Entwicklungszeit. Die Einrichtungszeit für eine gute Enterprise-Konfiguration amortisiert sich in der ersten Woche.

10. Zusammenfassung

PhpStorm für große Monorepos und Enterprise-Projekte zu konfigurieren bedeutet, die Standardeinstellungen konsequent anzupassen: Indexing-Excludes verhindern, dass PhpStorm unnötige Verzeichnisse analysiert. Heap-Erhöhung auf 4–6 GB vermeidet GC-Pausen bei großen Projekten. Scopes begrenzen Inspektionen und Suche auf den eigenen Code. Inspection-Profile zeigen nur relevante Warnungen. Settings-Sharing über .idea/-Dateien sorgt für Team-Konsistenz. Plugin-Reduktion verbessert Start-Performance und Speicherverbrauch.

Für Magento-Projekte ist die wichtigste Maßnahme die korrekte Klassifizierung von vendor/ als Library Root und pub/static/ sowie var/ als Excluded. Diese zwei Änderungen allein reduzieren die Indexing-Zeit und den Speicherbedarf erheblich. In Kombination mit einem auf den Mironsoft-Code beschränkten Scope und einem projektspezifischen Inspection-Profil arbeitet PhpStorm wieder wie ein Produktivitätswerkzeug, nicht wie ein Ressourcenfresser.

11. FAQ: PhpStorm Settings für Enterprise-Projekte