Salta el contingut

Composer

Introducció

Abans de tot, cal definir què és un compoment o paquet en PHP. Un component PHP és un conjunt de codi reutilitzable que t’ajuda a solucionar un problema específic de la teua aplicació. Aquests components solen estar formats per diverses classes. Composer és una eina que permet gestionar components en PHP.

Composer permet declarar els components dels que depèn el nostre projecte i gestionar-los (instal·lar/actualitzar). A diferència dels gestors de paquets com Apt o Yum, Composer gestiona els paquets per projecte, instal·lant-los en el directori (vendor).

Per defecte, no instal·la res de forma global. Per tant, és un gestor de dependències. Aquesta idea no és nova i Composer s’inspira fortament en npm de Nodejs i el bundler de ruby.

Composer ens soluciona dos problemes:

  • Gestionar les dependències amb llibreries de tercers. Només cal que declarem les dependències i Composer s'encarregarà de descarregar i instal·lar tot el que siga necessari
  • Autoloading del nostre codi. Ja no haurem de fer més require, Composer ho farà per nosaltres

Composer manté la seua configuració en dos fitxers: composer.json i composer.lock.

  • composer.json conté la informació de configuració principal del projecte. Aquí és on especifiques les dependencies del teu projecte, les versions que vols utilitzar, i altres configuracions com ara autoloaders, scripts post-instal·lació, etc. És un fitxer en format JSON i se sol mantenir al repositori del teu projecte perquè altres desenvolupadors puguin veure i reproduir la configuració del teu entorn.
  • composer.lock és generat automàticament per Composer després de la instal·lació de dependències o quan es fa una actualització. Conté una llista exacta de les versions de cada paquet que s'han instal·lat, així com les seves dependències. Això assegura que tots els desenvolupadors o servidors que treballin amb el mateix codi utilitzin les mateixes versions de les dependencies, evitant possibles problemes de compatibilitat.

Com hem dit, en usar Composer el primer que necessitem és disposar de l’arxiu composer.json. En aquest fitxer existeixen un seguit d'estructures d'informació:

{
    "require": {
        "monolog/monolog": "2.0.*"
    }
}

Gestió de dependècies

Instal·lació de paquets

Amb el paràmetre require podem instal·lar els paquets que requerix la aplicació, després els mapeja (en l’exemple, monolog/monolog) a la versió requerida (en aquest cas: 2.0.*).

Si necessitàrem usar en un projecte el component monolog executariem en la carpeta del projecte:

composer require monolog/monolog

Com hauràs observat el nom del paquet està format per dues parts:

  • La primera indica qui és el seu "vendor" o creador.
  • La segona indica el nom del projecte.

composer require vendor/package
Sovint les dues parts són idèntiques.

Versionat semàntic (SemVer)

Per poder controlar la versió dels paquets s'utilitza el versionat semàntic, un estàndar de facto per a la numeració de versions. Aquest sistema consta de tres parts principals en el número de versió: Major, Minor i Patch, que s'expressen com "MAJOR.MINOR.PATCH".

  • Major: S'incrementa quan es fan canvis incompatibles amb versions anteriors o quan es realitzen canvis importants que afecten la funcionalitat del programa.
  • Minor: S'incrementa quan s'afegeixen funcionalitats noves de manera compatible amb versions anteriors. És a dir, no afecta la compatibilitat enrere.
  • Patch: S'incrementa quan es realitzen correccions d'errors (bug fixes) compatibles amb les versions anteriors.

Podeu trobar més informació en el següent document: http://semver.org/lang/es/

Limitació de la versió dels paquets

En alguns casos és necessari limitar les versions dels paquetes per mantindre compatibilitat. Hi ha diverses formes d'expressar dites limitacions:

  • Restricció de la versió exacta
    • Exemple: 1.0.2 #MAJOR.MINOR.PATCH.
  • Rang de versions
    • Exemples:
    • >=1.0
    • >=1.0 <2.0
    • >=1.0 <1.1 || >=1.2
  • Rang de versions comodins (.*)
    • Es pot especificar un patró en un * comodí. 1.0.* és l'equivalent de >=1.0 <1.1.
    • Exemple: 1.0.*
  • Rang amb tilde (~)
    • L'operador ~ s'explica millor en un exemple: ~1.2 és equivalent a >=1.2 <2.0.0, mentre que ~1.2.3 és equivalent a >=1.2.3 <1.3.0.
    • Exemple: ~1.2
  • Rang de versió amb cimcurflex (^)
    • Per exemple ^1.2.3 és equivalent a >=1.2.3 <2.0.0 ja que ninguna de les releases fins a la 2.0 deuria trencar compatibilitat en versions anteriors.
    • Exemple: ^1.2.3

Instal·lació dependències

L’ordre install comprova primer si existeix el fitxer composer.lock, i si existeix, descàrrega exactament les versions que s'indiquen en aquest.

Si treballem en equip, tot l'equip tindrà les mateixes versions.

Executem la següent ordre:

composer install
Es generarà el directori vendor/ amb les llibreries de les quals depèn el projecte.

directori vendor

Hem d'afegir el directori vendor/ a l'arxiu .gitignore, perquè crea gran quantitat de fitxers que després s'han de descarregar amb composer install.

L’ordre també crea un fitxer composer.lock

Actualització de paquets

Si tenim l'arxiu composer.lock sempre s'instal·laran les mateixes versions dels paquets.

Per actualitzar a noves versions, fem servir l’ordre composer update. Aquesta ordre fa que Composer busque les versions més recents dels paquets sempre que seguisquen complint les restriccions de les versions indicades al fitxer composer.json. També actualitza l'arxiu composer.lock.

Si només volem instal·lar o actualitzar una dependència, podem indicar el seu nom després de l’ordre:

composer update monolog/monolog

No actualitzar en producció

Quan desplegues una aplicació basada en Composer a producció, usa sempre composer install. No haurieu d'usar mai composer update ja que podria ser que s'actualitzara algun paquet a una versió no provada.

Addició de dependències

L’ordre que afegeix noves dependències en el arxiu composer.json:

composer require

Ens preguntarà quines llibreries volem afegir.

Després d'afegir aquestes noves dependències, s’instal·len o actualitzen les dependències que siguen necessàries. Podem passar les noves dependències com argument de l'ordre.

composer require monolog/monolog:

Packagist

Packagist és el repositori central de paquets que pot gestionar Composer.

Lloc Web: http://packagist.org

Càrrega automàtica de classes

Normalment els paquets proporcionen informació sobre la càrrega automàtica de les seves classes. Així, Composer genera un fitxer vendor/autoload.php.

Incloent aquest fitxer en el projecte, podem utilitzar qualsevol classe instal·lada a través de Composer sense haver de incloure-la explícitament:

require 'vendor/autoload.php';

vendor/autoload.php

autoload.php és el punt d'entrada de l'aplicació a totes les funcionalitats que ens oferix Composer.

Càrrega de classes personalitzades

Podem emprar l’autoloader de Composer per a carregar les nostres classes. Si el nostre namespace és App i els arxius estan en src afegirem:

    "autoload": {
        "psr-4": { "App\\": "src/" }
    }

Després executarem composer dump-autoload perquè és regenere vendor/autoload.php.

PSR-4

PSR-4 (PHP Standard Recommendation) és una de les recomanacions del PHP-FIG per a implementar el sistema de càrrega automàtica de classes. PHP-FIG (Framework Interoperability Group). La idea del grup és que els representants del projecte parlen sobre els punts en comú entre els seus projectes i troben maneres de treballar junts.