Co to Composer? – Dyrygent Twojego projektu

Pracując nad projektem na pewno nie raz korzystałeś z zewnętrznych pakietów czy bibliotek. Często w jednym projekcie jest ich wiele i zaczyna pojawiać się problem z zarządzaniem nimi. Naprzeciw wychodzi nam właśnie Composer. To narzędzie na pewno zna większość programistów. Tym bardziej Ci, którzy pracują z Symfony. Dzisiaj pokażę Ci podstawy korzystania z Composera, ale także pare sztuczek, które mogą Ci się przydać.

Co to Composer?

Composer to narzędzie do zarządzania pakietami i bibliotekami używanymi w projekcie. Napisany jest w języku PHP. Pozwala on w bardzo prosty sposób nie tylko zarządzać, ale i pobierać potrzebne paczki. Podobnym narzędziem do Composera, o którym mogłeś słyszeć jest PEAR.

Instalacja jest banalnie prosta. Wystarczy wpisać zaledwie dwie komendy aby composer był dostępny:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

Po przeniesieniu pliku composer.phar będziemy mieli na swoim środowisku dostęp do komendy composer.

Podstawowy plik

Najważniejszym plikiem jest plik composer.json. To on dyryguje wszystkimi pakietami. Wystarczy że w swoim projekcie wywołamy komendę

composer init

a zobaczymy, że powstał właśnie ten plik. Jak wskazuje rozszerzenie, jego struktura jest zgodna ze strukturą jsona. Jako przykład wzięłam go z jednego z moich projektów. Projekt bazuje na Symfony 4.

{
    "type": "project",
    "license": "proprietary",
    "require": {
        "php": "^7.1.3",
        "ext-iconv": "*",
        "ext-json": "*",
        "ext-pdo": "*",
        "egulias/email-validator": "^2.1",
        "friendsofsymfony/rest-bundle": "^2.3",
        "gfreeau/get-jwt-bundle": "^2.0",
        "jms/serializer-bundle": "^3.3",
        "knplabs/gaufrette": "^0.6.0",
        "lexik/jwt-authentication-bundle": "^2.5",
        "mhujer/jms-serializer-uuid": "*",
        "nelmio/api-doc-bundle": "^3.2",
        "nelmio/cors-bundle": "^1.5",
        "ramsey/uuid": "^3.7",
        "ramsey/uuid-doctrine": "^1.4",
        "sensio/framework-extra-bundle": "^5.2",
        "stof/doctrine-extensions-bundle": "^1.3",
        "symfony/apache-pack": "^1.0",
        "symfony/asset": "^4.2",
        "symfony/console": "^4.2",
        "symfony/dotenv": "^4.2",
        "symfony/expression-language": "^4.2",
        "symfony/flex": "^1.0",
        "symfony/form": "^4.2",
        "symfony/framework-bundle": "^4.2",
        "symfony/lts": "^4@dev",
        "symfony/monolog-bundle": "^3.1",
        "symfony/orm-pack": "*",
        "symfony/process": "^4.2",
        "symfony/security-bundle": "^4.2",
        "symfony/serializer-pack": "*",
        "symfony/swiftmailer-bundle": "^3.2",
        "symfony/templating": "^4.2",
        "symfony/translation": "^4.2",
        "symfony/twig-bundle": "^4.2",
        "symfony/validator": "^4.2",
        "symfony/web-link": "^4.2",
        "symfony/webpack-encore-pack": "^1.0",
        "symfony/yaml": "^4.2",
        "twig/twig": "^2.5",
        "vich/uploader-bundle": "^1.9"
    },
    "require-dev": {
        "behat/behat": "^3.4",
        "doctrine/data-fixtures": "^1.3",
        "escapestudios/symfony2-coding-standard": "^2.0",
        "hautelook/alice-bundle": "^2.3",
        "phing/phing": "^2.16",
        "phpmd/phpmd": "^2.6",
        "phpunit/phpunit": "^7.2",
        "roave/security-advisories": "dev-master",
        "sebastian/phpcpd": "*",
        "squizlabs/php_codesniffer": "^2.0",
        "symfony/debug-pack": "*",
        "symfony/maker-bundle": "^1.0",
        "symfony/profiler-pack": "*",
        "symfony/test-pack": "^1.0",
        "symfony/web-server-bundle": "^4.2",
        "theofidry/alice-data-fixtures": "^1.0",
        "wimg/php-compatibility": "^9.1"
    },
    "config": {
        "bin-dir": "bin",
        "preferred-install": {
            "*": "dist"
        },
        "sort-packages": true
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\\Tests\\": "tests/"
        }
    },
    "scripts": {
        "auto-scripts": {
            "cache:clear": "symfony-cmd",
            "assets:install %PUBLIC_DIR%": "symfony-cmd"
        },
        "post-install-cmd": [
            "@auto-scripts"
        ],
        "post-update-cmd": [
            "@auto-scripts"
        ]
    },
    "conflict": {
        "symfony/symfony": "*"
    },
    "extra": {
        "symfony": {
            "allow-contrib": "true"
        }
    }
}

Idąc po kolei, pierwsze elementy to type i license, które są ważne, jeśli swoją paczkę wypuszczasz w świat. Osobiście nigdy nie zwracałam na nie szczególnej uwagi. Type to oczywiście typ paczki, w naszym przypadku to cały projekt. License zawiera informację o typie licencji z jaką rozpowszechniana jest dana paczka.

Element require zawiera listę paczek wymaganych w projekcie niezależnie od trybu z jakim odpalona jest aplikacja. O co chodzi? W całym pliku możesz zauważyć element require i require-dev, różnią się tym, że paczki wymagane do działania aplikacji require będą zawsze wymagane i instalowane w każdym trybie aplikacji, a te z require-dev tylko w trybie developerskim. Jeśli byłby to compser.json dla paczki, którą instaluje się w innych projektach to require zawierałby wszystkie paczki, które muszą być również zainstalowane w projekcie przy instalacji tej konkretnej, o ile jeszcze ich nie ma.

Config jest elementem wykorzystywanym tylko w przypadku gdy przygotowujemy composer.json dla projektu i zawiera różne opcje konfiguracyjne jak sama nazwa wskazuje.

Autoload i autoload-dev różnią się analogicznie co require i require-dev. Zawierają one informację o mapowaniu ścieżek w PHP.

Scripts powala wstrzelić się różne etapy instalacji pakietów. W przykładzie akurat natywny kod Symfony.

W elemencie conflict możemy wpisać nazwy paczek i ich wersje, z którymi nasza paczka czy projekt się konfliktuje i nie będzie możliwe jej instalacja czy współdziałanie naszych paczek. Może zdziwi Was teraz to dlaczego composer.json z Symfony konfliktuje się z paczką symfony/symfony. Chodzi o to, że między wersją Symfony 3 i 4 nastąpiły bardzo duże zmiany w strukturach paczek. W wersji 3 prawie całe Symfony było w jedej paczce symfony/symfony, a w 4 zostało to rozbite na wiele mniejszych paczek. Stąd nie można w Symfony 4 zainstalowac paczki Symfony z wersji 3.

Element extra zawiera dodatkowe informację wykorzystywane przez skrypty z elementu scripts.

Przydatne komendy

composer install

Instaluje pakiety zdefiniowane w pliku compser.json.

composer update

Obok paczek definiujesz także ich wersje. Jeśli wersja, która jest zainstalowana jest przestarzała bądź niezgodna to ta komenda wyrównają do wymaganej bądź najbardziej aktualnej.

composer require autor/nazwa

Komenda dodaje wpis do elementu require, chyba, że dodamy parametr –dev. Wtedy zależność wpadnie do require-dev.

composer dump-autoload

Generuje plik autoload.php zawierające mapowanie ścieżek.

composer self-update

Aktualizuje samego composera.

composer clear-cache

Czyści cache composera, który tworzy się przy instalacji paczek.

composer create-project

Tworzy nowy projekt.

Podsumowanie

Composer jest narzędziem, z którym programiści spotykają się na co dzień. Większość frameworku bazują właśnie na composerze jak Symfony, Laravel, Magento itd. Warto poznać jego podstawy zanim zaczniemy pracę. Podstawowy plik może nam również wiele powiedzieć o projekcie, który poznajemy. Poszczególne elementy na pewno będziesz miał okazję zgłębić z czasem i doświadczeniem. A Ty jakie masz doświadczenia? Spotkałeś się z jakimś ciekawym trikiem? Podziel się nim ze mną w komentarzu!

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here