Logo

Warum du deine Adobe Commerce Module in Pakete verpacken solltest

Vlad Sikailo

Vlad Sikailo

13/05/2025

Minuten Lesezeit

Technical
Warum du deine Adobe Commerce Module in Pakete verpacken solltest

Inhalte

Warum du deine Adobe Commerce Module in Pakete packen solltest

Einleitung

Üblicherweise speichert man Adobe Commerce Module im Verzeichnis app/code/<vendor>/. In diesem Blogpost zeige ich dir eine alternative Methode und erkläre Dir, warum du sie in Betracht ziehen solltest.

Vorgehensweise

Bei run_as_root behandeln wir Custom-Module wie Composer-Packages.
Für jedes unserer Module erstellen wir ein eigenes Composer-Package, legen es im src/-Verzeichnis ab und binden es per Composer ein.

/images/blog/why-you-should-package-your-modules/src-modules.png

Wenn du wissen möchtest, wie man ein Modul zum Composer-Package macht, schau dir die Anleitung im Adobe Developer Portal an.

Warum ist das wichtig?

Der Hauptgrund dafür ist, Abhängigkeiten zwischen deinen Modulen mit Composer zu managen.

Ist es dir schon mal passiert, dass du ein Modul gelöscht hast, aber in einem anderen Modul immer noch eine Abhängigkeit drauf war? 😱

Die klassische bekannte Deklaration in module.xml hilft hier nicht weiter, denn das <sequence>-Tag steuert nur die Lade-Reihenfolge – es prüft nicht, ob ein Modul überhaupt existiert oder entfernt wurde.

Wie wir gesehen haben, funktioniert diese Methode zum Verwalten von Projekt-Abhängigkeiten nicht zuverlässig. Composer ist jedoch genau dafür gemacht – also warum nicht Composer das machen lassen?

Best Practice

Wie wir jetzt wissen, ist der einzige echte Weg, Abhängigkeiten deiner Custom-Module zu verwalten, Composer zu nutzen.
Dabei musst du sie sowohl in composer.json als auch in module.xml angeben:

  1. In composer.json, um fehlende Abhängigkeiten zu verhindern:
    Wenn jemand versucht, ein Modul zu entfernen, von dem ein anderes abhängt, wirft Composer sofort einen Fehler.
  2. In module.xml, um die richtige Lade-Reihenfolge sicherzustellen.

So sieht’s in der composer.json aus:

1{
2 "name": "vendor/module-name",
3 "description": "Beschreibung deines Moduls",
4 "version": "1.0.0",
5 "require": {
6 "vendor/dependency-module": "^1.0"
7 },
8 "type": "magento2-module",
9 "autoload": {
10 "files": [
11 "registration.php"
12 ],
13 "psr-4": {
14 "Vendor\\ModuleName\\": ""
15 }
16 }
17}

Und so in der module.xml:

1<?xml version="1.0"?>
2<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
3 <module name="Vendor_ModuleName">
4 <sequence>
5 <module name="Vendor_DependencyModule"/>
6 </sequence>
7 </module>
8</config>

Hast du alle Abhängigkeiten sauber deklariert, kannst du dich getrost zurücklehnen und Composer den Rest erledigen lassen.

Vergiss nicht, während der Modul-Entwicklung diesen Magento best practices zu folgen:

  • Mehrere Module dürfen nicht für ein und dieselbe Funktionalität verantwortlich sein.
  • Ein Modul darf nicht für mehrere Funktionalitäten zuständig sein lassen.
  • Abhängigkeiten zwischen Modulen immer explizit deklarieren.
  • Das Entfernen oder Deaktivieren eines Moduls darf nicht automatisch andere Module ausschalten.

Und denk dran: Ein wichtiger Aspekt sauberer Architektur ist, Module möglichst ohne Abhängigkeiten zu entwickeln.

So geht’s weiter

  • Um die Kopplung deiner Module zu analysieren, kannst du PhpMetrics nutzen.
  • Für einen schnellen Dependency-Check gibt’s das CLI-Tool von run_as_root - Magento 2 Dependency Checker
  • Am besten packst du das in deine CI/CD-Pipeline, damit immer alles sauber bleibt. Für GitLab findest du eine Open-Source-Pipeline-Vorlage von run_as_root hier: Integrity Checker Vorlage

Fazit

Kurz zusammengefasst:

  • Überlege, deine Projekt-Module als Composer-Pakete auszuliefern.
  • Deklariere alle Abhängigkeiten sowohl in composer.json als auch in module.xml.
  • Folge den Magento-Best-Practices bei der Modul-Entwicklung.
  • Entwickle deine Module möglichst ohne Abhängigkeiten.

Bereit, modularen Code zu meistern?

Vereinbare eine Session mit Vlad und lass dir alle Fragen beantworten.

Jetzt Termin vereinbaren

Weitere Beiträge

Technical
/images/blog/blog-crafting-code-that-lasts_thumbnail.webp
Rico Neitzel Avatar

Rico Neitzel

11.03.25

Crafting Code That Lasts
Technical
images/blog/automation-done-right/automation-poster-desktop.webp
Matthias Walter Avatar

Matthias Walter

18.12.24

Automatisierung - aber richtig