Programmiergrundlagen für Add-on-Entwickler
Sprachen, Schnittstellen, Build-Werkzeuge, Versionskontrolle und Tests: das Handwerkszeug, das für Erweiterungen jeder Plattform gebraucht wird.
Add-ons sind kleine Programme, aber sie leben in einer anspruchsvollen Umgebung. Sie laufen in fremder Software, deren Updates sie nicht kontrollieren, teilen sich den Platz mit anderen Erweiterungen und haben oft Zugriff auf sensible Daten. Wer Add-ons entwickelt, braucht deshalb nicht nur Sprachkenntnisse, sondern auch ein Gefühl für Schnittstellen, Werkzeuge und saubere Arbeitsweisen. Dieser Bereich bündelt das Handwerkszeug, das plattformübergreifend gilt.
Welche Sprache für welche Plattform?
| Plattform | Hauptsprache | Ergänzend |
|---|---|---|
| Browser-Erweiterungen | JavaScript, TypeScript | HTML, CSS |
| WordPress | PHP | JavaScript (Blöcke), SQL |
| VS Code | TypeScript | JSON (Manifest) |
| JetBrains-IDEs | Kotlin, Java | XML (Manifest) |
| Microsoft Office | JavaScript, TypeScript | HTML, CSS |
| Google Workspace | JavaScript (Apps Script) | HTML für Seitenleisten |
| phpBB, XenForo, MyBB | PHP | Templates, SQL |
| Discourse | Ruby, JavaScript | SCSS |
| Minecraft Java Edition | Java | JSON |
JavaScript und TypeScript decken damit den größten Teil ab. Wer nur eine Sprache lernen will, fängt dort an.
Ereignisgesteuert denken
Das wichtigste Konzept der Add-on-Entwicklung ist die Umkehrung der Kontrolle. Ein normales Programm startet und bestimmt selbst, was als Nächstes passiert. Ein Add-on dagegen meldet sich bei der Host-Anwendung an und wartet: auf einen Klick, eine geladene Seite, einen gespeicherten Beitrag oder einen Befehl. Je nach Plattform heißen diese Andockstellen Ereignisse, Hooks, Events oder Contribution Points, gemeint ist immer dasselbe.
Daraus folgen einige Gewohnheiten:
- Asynchron arbeiten. Fast jeder Zugriff auf Browser-Tabs, Dokumente oder Netzwerkdaten liefert ein Promise.
asyncundawaitmachen den Code lesbar. Fehlendeawaitsind eine der häufigsten Fehlerquellen. - Zustand bewusst speichern. Ihr Code wird bei Bedarf gestartet und wieder beendet. Was erhalten bleiben soll, gehört in den Speicher der Plattform, nicht in eine globale Variable.
- Aufräumen. Registrierte Listener, Timer und Oberflächenelemente müssen beim Deaktivieren wieder entfernt werden.
Paketmanager und Build-Werkzeuge
Kaum ein Add-on kommt ohne fremde Bibliotheken aus. npm (oder Alternativen wie pnpm) verwaltet sie in JavaScript-Projekten, Composer in PHP-Projekten. Ein Build-Werkzeug wie Vite oder esbuild übersetzt TypeScript, bündelt Module zu wenigen Dateien und entfernt ungenutzten Code. Manche Plattformen liefern eigene, vorkonfigurierte Werkzeuge mit, etwa @wordpress/scripts für Gutenberg-Blöcke.
Jede Bibliothek vergrößert das Paket, verlängert die Prüfung im Store und ist ein mögliches Sicherheitsrisiko. Prüfen Sie vor jeder neuen Abhängigkeit, ob die Plattform die Funktion nicht schon selbst mitbringt.
Versionskontrolle mit Git
Git ist das Sicherheitsnetz jedes Entwicklungsprojekts. Jeder Commit hält einen Stand fest, Branches erlauben Experimente, ohne die funktionierende Version zu gefährden. Für Add-ons besonders nützlich sind Tags: Markieren Sie jede veröffentlichte Version mit einem Tag wie v1.2.0. Meldet jemand einen Fehler in dieser Version, können Sie den Stand jederzeit exakt wiederherstellen.
Testen
Die Host-Anwendung ändert sich, Ihr Add-on soll trotzdem funktionieren. Automatisierte Tests sind der beste Weg, Brüche früh zu erkennen:
- Unit-Tests prüfen einzelne Funktionen ohne die Host-Anwendung, etwa eine Funktion, die Text umwandelt.
- Integrationstests laufen in einer echten oder simulierten Umgebung der Plattform, zum Beispiel in einer Testinstanz von VS Code oder einer lokalen WordPress-Installation.
- End-to-End-Tests steuern die Anwendung wie ein Mensch. Werkzeuge wie Playwright können einen Browser mit geladener Erweiterung starten und Klickpfade durchspielen.
Was aus der allgemeinen Softwareentwicklung zählt
Viele Prinzipien der professionellen Softwareentwicklung gelten auch für ein Ein-Personen-Add-on, nur in kleinerem Maßstab. Kurze Entwicklungszyklen, wie sie agile Methoden propagieren, passen gut zu Erweiterungen: lieber regelmäßig kleine, getestete Versionen ausliefern als selten große. Continuous Integration, also das automatische Bauen und Testen bei jedem Commit, lässt sich mit kostenlosen Diensten der Code-Hoster einrichten und fängt Fehler ab, bevor sie Nutzer erreichen. Code-Reviews sind auch allein möglich: Lesen Sie Ihre Änderungen am nächsten Tag noch einmal, bevor Sie sie veröffentlichen.
Auch Werkzeuge mit künstlicher Intelligenz haben die Arbeit verändert. Sie schreiben Gerüste, erklären unbekannte APIs und schlagen Tests vor. Gerade bei Add-ons ist aber Vorsicht geboten: Die Schnittstellen ändern sich schnell, und generierter Code nutzt mitunter veraltete Funktionen oder zu weite Berechtigungen. Prüfen Sie Vorschläge gegen die aktuelle Dokumentation der Plattform.
Sicherheit von Anfang an
Ein Add-on erbt die Rechte der Anwendung, in der es läuft. Sicherheitsgrundsätze gehören deshalb zu den Grundlagen und nicht ans Ende des Projekts: nur die Berechtigungen anfordern, die wirklich gebraucht werden, Eingaben prüfen, Ausgaben maskieren, keine Geheimnisse wie API-Schlüssel ins Paket schreiben und Abhängigkeiten aktuell halten. Wie das auf den einzelnen Plattformen aussieht, steht in den Bereichen zu Browser-Erweiterungen und WordPress-Plugins, die Sicht der Nutzer im Bereich Sicherheit.
Anleitungen zu Grundlagen
- Erweiterungen testen mit Playwright
Wie Sie eine Chrome-Erweiterung in Playwright laden, Popup, Content Scripts und Service Worker in End-to-End-Tests prüfen und die Tests in einer CI-Pipeline laufen lassen.
- TypeScript und Vite einrichten
Ein Build-Setup für Erweiterungen: TypeScript-Konfiguration, Typen für die Browser-APIs, mehrere Einstiegspunkte mit Vite, die Sonderrolle der Content Scripts und Alternativen wie WXT.
Fragen und Antworten
- Reicht JavaScript für den Einstieg in die Add-on-Entwicklung?
- Für Browser-Erweiterungen, VS-Code-Extensions, Office-Add-ins, Google Apps Script, Obsidian und Figma ja. Für WordPress-Plugins und viele Foren brauchen Sie zusätzlich PHP, für Minecraft-Mods Java und für JetBrains-Plugins Kotlin oder Java.
- Lohnt sich TypeScript für kleine Erweiterungen?
- Meist ja. Die Schnittstellen der großen Plattformen sind als Typdefinitionen verfügbar. Der Editor schlägt dadurch Methoden und Parameter vor und meldet Tippfehler, bevor die Erweiterung überhaupt geladen wird. Der zusätzliche Build-Schritt ist mit modernen Werkzeugen schnell eingerichtet.
- Brauche ich als Hobby-Entwickler Git?
- Unbedingt. Git kostet nichts, sichert jeden Zwischenstand und macht es leicht, eine Änderung rückgängig zu machen, die nach einem Update der Host-Anwendung Probleme verursacht. Viele Stores und Verzeichnisse setzen zudem ein öffentliches Repository voraus oder empfehlen es.
Weiterlesen
- Browser-Erweiterungen
Manifest V3, Service Worker, Content Scripts und Popup: wie eine Erweiterung aufgebaut ist, wie Sie sie lokal testen und in welchen Stores sie landet.
- WordPress-Plugins
Vom Plugin-Header über Actions und Filter bis zu Gutenberg-Blöcken: wie ein sauberes WordPress-Plugin aufgebaut ist und worauf das Plugin-Verzeichnis achtet.
- Glossar
Von Add-on bis WebExtensions: die wichtigsten Fachbegriffe der Plugin-Entwicklung in kurzen, plattformübergreifenden Erklärungen.