Discutii despre composer.json si composer.lock

Mi-am dat seama ca nu stiu prea multe lucruri despre composer, mai exact nu stiu ce face composer.json, ce e composer.lock, care este diferenta dintre composer install si composer update...asa ca am inceput sa citesc.

Asa ca am decis sa impart si cu voi aceste infomatii, in acest articol.

Ce este composer?

Composer este un manager de dependinte pentru PHP, iti permite sa foloseste pachetele de care aplicatia ta are nevoie pentru a functiona. 

Hai sa facem o lista cu ce stie composer sa faca:

• Stiu sa faca management de dependinte

• Autoloading PSR

• Optimizarea compilatorului pentru o viteza mai mare

• Este conectat la ciclul de viata al aplicatiei si se poate conecta la diferite evenimente (ex: installed, updated, created, etc)

• Verificarea stabilitatii

Folosind editorul de text preferat, haideti sa deschidem composer.json din root-ul proiectului tau. 

Informatii Meta

In prima parte a fisierului gasim meta informatiile:

"name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
"framework",
"laravel"
],
"license": "MIT",

Aceste informatii sunt folosite de Packagist, site care catalogheaza pachetele disponibile. Ca si standard, daca vreti sa scrieti un pachet ce va fi disponibil pe packagist trebuie sa da-ti numele pachetului la fel ca repository-ul de pe github.

Manager de dependinte

Apoi, gasim blocul de require, bloc ce ne ajuta la managementul dependintelor. In clipa de fata continutul acestui bloc ar trebui sa fie destul de simplu, avand in vedere ca avem numai laravel-ul.

"require": {
"php": "^7.1.3",
"fideloper/proxy": "^4.0",
"laravel/framework": "5.8.*",
"laravel/tinker": "^1.0"
},

Pare destul de simplu, nu? O chestie pe care vreau sa o mai discut aici este versiunea. Dupa cum vedeti,pot aparea mai multe valori, de exemplu ^4.0, ~4.1, >=1.0, <1.1, etc. Eu am sa scriu o explicatie scurta aici, dar mai multe informatii puteti gasi aici:  https://getcomposer.org/doc/01-basic-usage.md#package-version-constraints

Autoloading

Mai sus am scris despre composer ca vine cu un autoloader, ba chiar si un sistem de optimizare pentru PHP. Stie sa faca aceste lucruri datorita sectiunii de autoload sin composer.json

"autoload": {
    "psr-4": {
        "App\\": "app/"
    },
    "classmap": [
        "database/seeds",
        "database/factories"
    ]
},

Aici putem folosi autoload-ul PSR (daca nu stii ce este asta poti citi aici: https://www.php-fig.org/psr/psr-4/). Laravel 5 foloseste PSR-4, spre deosebire de Laravel 4. 

Ce se intampla in codul de mai sus? Pai autoloader-ul va cautafisierele din folderul app/ si le va incarca in aplicatie, de exeplu daca avem un fisier app/Services/FooService.php cu namespace-ul App\Services\FooService il vom putea folosi in alte fisiere folosind sintaxa use App\Services\FooService;

Scripturi si Hook-uri in lifecycle

Acum o sa discutam despre o serie de scripturi ce pot fi executate dupa composer install, update sau create-project.

"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ],
    "post-root-package-install": [
        "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
    ],
    "post-create-project-cmd": [
        "@php artisan key:generate --ansi"
    ]

}

Composer ne permite sa ne legam la anumite evenimente pentru a rula automat comenzi. Eu unul le folosesc pentru chestii gen migratii atunci cand fac deploy pe server. Deploy-ul poate fi redus la 2 pasi simpli:

1. git pull

2. composer install

Atentie totusi, acesta este un articol despre composer, nu despre procesul de deployment.

Diferenta dintre composer update si composer install

In primul rand composer update face 2 lucruri

    1.va updata pachetele required la ultima versiune declarata

    2.va updata composer.lock cu versiunile exacte

Composer install va instala dependintele listate in composer.lock, in schimb, daca acest fisier nu exista, aceasta comanda va face fix acelasi lucru ca si composer update.

Sa ne gandim la urmatoarea situatie, rulam composer pe masina 1, iar mai tarziu si pe masina 2. Trebuie sa ne asiguram ca pachetele folosite sunt identice pe ambele masini. Daca rulam composer update pentru fiecare masina pe rand exista o sansa ca pachetele folosite sa difere. Ne putem imagina ca un anumit feature al unui pachet la o versiune functioneaza bine, iar la alta versiune da eroare...din asta va rezulta ca masina cu a doua versiunbe a pachetului sa dea eroare si noi sa nu ne putem da seama de la ce este

In acest caz am putea sterge vendorul din .gitignore si sa comitem totul, dar exista o metoda mai buna. Fisierul .lock are deja hash-urile necesare, care nu ar trebui sa se schimbe, iar noi il putem folosi in avantajul nostru urmand urmatorul principiu: Pe mediul de dev rulam numai composer update, niciodata pe mediul de prod.

Stability

Am ajuns aproape desfarsitul fisierului composer.json

"config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "sort-packages": true
},

Composer poate lua pachetele din codul sursa sau din din zip-uri, tocmai pentru asta se foloseste flag-ul preferred-install. Mai multe inforamtii despre acest flag:  https://getcomposer.org/doc/06-config.md#preferred-install

Rulare

Composer poate fi descarcat de pe https://getcomposer.org/. O data ce a fost instalat, il  putem verifica folosind comanda

composer -v

Mai sunt si alte comenzi, de exemplu in loc sa editam fisierul composer.json putem folosi comanda

composer require

Alta comanda utila este validate, oricata experienta ai avea tot este bine sa te asiguri ca totul este scris corect dupa fiecare modificare facuta.