Composer verstehen - Teil 3 - composer.json

von

Als nächstes werfen wir einen Blick in die composer.json Datei. Man sollte diese Datei nämlich verstehen, damit man einerseits Composer besser versteht, aber auch selbst Anpassungen an dieser Datei machen kann.

Wir erstellen dafür ein kleines Setup: Contao 4 mit dem Notification Center als Zusatzmodul. Natürlich erstellen wir alles mit Composer.

$ composer create-project contao/managed-edition my_composer_example
$ composer require terminal42/notification_center

Die composer.json Datei sieht dann wie folgt aus:

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^7.1",
        "contao/calendar-bundle": "^4.6",
        "contao/comments-bundle": "^4.6",
        "contao/faq-bundle": "^4.6",
        "contao/listing-bundle": "^4.6",
        "contao/manager-bundle": "4.6.*",
        "contao/news-bundle": "^4.6",
        "contao/newsletter-bundle": "^4.6",
        "terminal42/notification_center": "^1.5"
    },
    "conflict": {
        "contao-components/installer": "<1.3"
    },
    "require-dev": {
        "sensiolabs/security-checker": "^4.1"
    },
    "extra": {
        "branch-alias": {
            "dev-4.6": "4.6.x-dev"
        },
        "contao-component-dir": "assets"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

Wir gehen nun die einzelnen Bereiche durch.

name
Der Name des Projekts oder des Pakets. Der Name besteht aus dem Anbietername und dem Projekt-/Paketnamen, getrennt durch einen Slash /.

type
Die Art des Projekts oder des Pakets.
Pakettypen werden für die benutzerdefinierte Installationslogik verwendet. Wenn wir zum Beispiel ein Paket haben, das eine spezielle Logik benötigt, kann man einen benutzerdefinierten Typ definieren. Dies kann ein Symfony-Bundle, eine Contao-Erweiterung usw. sein. Diese Typen werden alle spezifisch für bestimmte Projekte definiert und müssen einen Installer bereitstellen, der in der Lage ist, Pakete dieses Typs zu installieren.

Oben wird jetzt der Typ "project" verwendet. Dies bezeichnet ein Projekt und kein Paket.

description
Eine kurze Beschreibung des Projekts/Pakets. Normalerweise ist die Beschreibung eine Zeile lang.

license
Die Lizenz, unter der das Paket steht. LGPL, GPL, MIT usw.

authors
Die Autoren des Pakets. Jedes Autorenobjekt kann folgende Eigenschaften haben:

  • Name: Der Name des Autors. Normalerweise der richtiger Name, kein Nickname
  • E-Mail: Die E-Mail-Adresse des Autors
  • Homepage: Die Website des Autors
  • Rolle: Die Rolle des Autors im Projekt (z.B. Entwickler oder Übersetzer)

require
Liste der für dieses Projekt/Paket benötigten Pakete.

Wir sehen hier nun, dass Contao 4.6 PHP 7.1 benötigt, sowie alle Standard-Module von Contao, welche neu Bundles sind (contao/calendar-bundle, contao/comments-bundle, usw.). Zudem ist klar definiert, in welcher Version das Paket (das Contao-Modul) vorliegen muss (^4.6 bedeutet >=4.6.0 <4.7.0)

Wir sehen hier auch, dass unser zusätzlich installiertes Modul (terminal42/notification_center) eingetragen wurde. Wieder mit der passenden Versionsbezeichnung (^1.5 bedeutet >=1.5.0 <1.6.0). Falls jetzt die Version 1.6.0 veröffentlich worden wäre, würde diese mit einem composer update nicht installiert werden, weil die Version ja auf 1.5.x geblockt ist. Möchte man die neuste Version erhalten, muss man hier die Version-Constraint auf ^1.6 anpassen (^1.6 bedeutet >=1.6.0 <1.7.0) gefolgt von einem composer update terminal42/notification_center.

Anstatt mit composer require kann man auch manuell weitere Pakete hier eintragen und mit composer install installieren lassen. Aber es empfiehlt sich, das mit composer require zu tun.

conflict
Pakete, die mit dieser Version dieses Projekts/Pakets in Konflikt stehen. Diese dürfen nicht zusammen mit dem Projekt/Paket installiert werden. In diesem Fall also contao-components/installer in der Version kleiner 1.3.

require-dev
Pakete, die nur für die Entwicklung, die Durchführung von Tests usw. benötigt werden. Die dev-Pakete werden standardmässig immer installiert. composer install und composer update unterstützen aber die Option --no-dev, welche die Installation von diesen dev-Paketen verhindert. Dies ist zum Beispiel nützlich für die Ausführung auf einem Produktiv-System, wo diese Pakete für die Entwicklung nicht benötigt werden.

extra
Unter extra können viele zusätzliche Informationen hinterlegt werden.
Hier in diesem Fall zum Beispiel der branch-alias - der dev-master Branch aus dem Repository. Es ist ziemlich häufig, dass jemand die neueste Master-Dev-Version haben möchte. So erlaubt Composer es, den dev-master Branch auf eine aktuelle Version zu aliasieren.
Oder man kann hier unter extras auch Patches hinterlegen. Mehr Infos zu Patches hier: Composer verstehen - Teil 4 - Patches

autoload
Autoload-Mappings für den PHP-Autoloader. PSR-4 und PSR-0 Autoloading, classmap und Datei-Includes werden unterstützt. PSR-4 ist empfohlen, da es eine einfachere Bedienung bietet. Mehr Infos zu Autoloading hier: Composer verstehen - Teil 5 - Autoloading

scripts
Composer ermöglicht es, Scripte an verschiedenen Stellen des Installations- und Update-, usw. Prozesses einzubinden. In unserem Beispiel wird die initializeApplication-Funktion von Contao immer nach einem composer install und composer update durchgeführt. Nach einem Befehl, wegen post-*. Es gibt natürlich auch vor einem Befehl mit pre-*. Siehe dazu die offizielle Dokumentation zu Command Events.

Zurück

Kommentare

Einen Kommentar schreiben

Was ist die Summe aus 2 und 2?