Magento 2 en Composer, hoe werkt het nou precies?

Gastblog van Peter Jaap Blaakmeer, CTO bij Elgentos
Als je jezelf al wat hebt verdiept in Magento 2 ben je vast al regelmatig de term ‘Composer’ tegengekomen. Misschien heb je er al in andere PHP projecten mee gewerkt of heb je, net als wij bij Elgentos, al een aantal Magento 1.x shops draaien met Composer. Maar wat is het nou eigenlijk? Wat doet het precies, en belangrijker nog, waarom zouden we het allemaal moeten gebruiken?

Wat is Composer precies?

Composer is een dependency management tool voor PHP. Ondanks dat veel developers denken dat het een package manager is, is dat niet het geval. Het verschil hier tussen zit vooral in het feit dat je met Composer (over het algemeen) een package (extensie/module, library of externe tool) binnen een project installeert, in plaats van op een specifieke omgeving (zoals je eigen computer).

Waarom wil je Composer (met Magento 2) gebruiken?

Of je nou met Magento 1 werkt of al aan een Magento 2 project begonnen bent, het werken met Composer maakt je leven een stuk makkelijker. Het grote voordeel van Composer is dat je er al je afhankelijkheden (libraries, extensies, themes, etc) binnen een project op één eenduidige manier mee kunt inzien en beheren. Moeten deze geüpdatet worden? Dan is dit met Composer binnen no time gebeurd, terwijl dit nu nog tijdrovend en lastig kan zijn. Om dit voor elkaar te krijgen heb je het bestand composer.json nodig in de root van je project. Het streven als developer moet zijn om alle code die je schrijft herbruikbaar te maken voor meerdere projecten. Dit verzamel je dan in een composerized module, oftewel een composer package.
Voorbeeld: Stel je gebruikt een extensie die gebouwd is door één of meerdere ontwikkelaars, en deze ontwikkelt zich verder over tijd. Wat gebeurt er dan als deze extensie geüpdatet wordt? Als je extensie in een project staat met Composer betekent dit dat je automatisch de nieuwste versie kunt binnenhalen en gebruiken. Met Composer heb je dan geen gedoe met zip-bestanden downloaden, uitpakken, handmatig bestanden overschrijven, niet gebruikte bestanden verwijderen etcetera. Composer regelt dit allemaal voor je. Het enige wat jij hoeft te doen is het versienummer van de extensie aanpassen binnen je composer.json, de composer.phar update te draaien en de update is binnen en klaar voor gebruik!
Let op: Bij Magento 1.x hoor je alleen de extensies in app/code/community te beheren in composer. De extensies in app/code/local zijn project specifiek en worden dus maar één keer gebruikt. Dit betekent dat ze zich dus niet lenen voor de voordelen van Composer.
Tip: Als je de spiksplinternieuwe Magerun Hypernode addons gebruikt zie je direct voor welke extensies/modules er updates beschikbaar zijn.

Wat heeft Composer met Magento 2 te maken?

Anders dan Magento 1, leunt Magento 2 volledig op Composer. Als je Magento 2 downloadt vanaf Github zie je direct dat er in deze repository weinig code zit. Dat komt omdat Magento 2 veel gebruik maakt van bestaande libraries zoals Zend Framework 2 modules, Symfony components, PHPUnit, PHPMD, OAuth, etcetera. Waar je bij Magento 1 deze in één keer moest downloaden vanaf magento.com wordt dit voor Magento 2 door Composer gedownload. Composer zorgt er vervolgens ook voor dat het binnen je Magento 2 installatie op de juiste plekken binnen je wordt geplaatst. Dit doe je door de composer.phar install te draaien. Zelfs de core modules van Magento 2 zijn Composer packages geworden. Dat kun je zien op de Magento’s Packagist pagina onder de kop ‘replace’.

Hoe werkt Composer met Magento 2 in de praktijk?

Composer bestaat eigenlijk uit drie onderdelen; twee bestanden (composer.json, composer.lock) en één binary (composer.phar). In de composer.json geef je aan welke packages het project nodig heeft. Daarna download je deze packages door composer.phar update uit te voeren. Composer downloadt niet alleen deze packages maar ook de dependencies van deze packages. Dit betekent dat niet alleen de packages die jouw project direct nodig heeft wordt gecontroleerd en bijgehouden, maar ook de packages waar jóuw package weer gebruik van maakt.
Om dit gecontroleerd te doen maakt Composer een zogenaamde lockfile aan, namelijk composer.lock. In deze lockfile staat exact welke commit uit de Git repository jouw package versie is, en welke specifieke code dus wordt gebruikt. Door deze lock file kan er niet onverwachts nieuwe code je project binnensluipen zonder dat je het getest zou kunnen hebben. Je commit zowel composer.json als composer.lock naar je Git repository, en vervolgens pull je de repository naar je productie. Omdat dit commando alleen kijkt naar de composer.lock, en niet naar de composer.json, zet hij met het gebruik van de composer.phar alleen de door jou geteste code live. Dit is belangrijk omdat het kan voorkomen dat er nieuwe code in een package zit die voor fouten in je Magento webshop zorgt. Dit wil je eerst getest hebben.

(Je eigen) Packages toevoegen aan Composer

Dé site voor packages voor Composer is Packagist. Hier staan vrijwel alle Open Source extensies voor Magento op. De Packagist repository is standaard toegevoegd aan Composer en daarom kun je veel extensies simpelweg installeren met composer.phar require vendorname/packagename. Hier kun je ook je eigen Open Source extensies toevoegen.
Een andere veelgebruikte repository voor Magento 1 is die van de Duitse Magento community Firegento; Firegento Packages. Ook hier kun je eigen Open Source Magento extensies toevoegen. Deze worden echter wel door Firegento gecheckt en kunnen afgekeurd worden om diverse redenen.
Maar wat als je veel interne extensies hebt die je niet “open en bloot” op Github wilt hebben? Dan heb je twee opties;

• Je interne (private) Git repositories direct toevoegen aan composer.json.
• Een interne repository server opzetten welke je vervolgens toevoegt aan je composer.json. Composer zal dan bij een ‘require’ ook binnen die server gaan zoeken. Een server opzetten doe je bijvoorbeeld met behulp van het open source pakket Satis [1] [2] [3].

Ga je hiermee aan de slag? Let er dan wel op dat Magento moet weten welke bestanden er bij jouw extensie horen. Er zijn drie manieren om Composer te vertellen welke bestanden binnen de package weer binnen je project horen. Dit heet een mapping. De meest gebruikte manier van mapping is door middel van een modman bestand. Modman is een tool specifiek geschreven voor de Magento community om het ontwikkelen van Magento 1 extensies zo simpel mogelijk te maken. Composer is de volgende stap hierin. Als je Composer wilt gebruiken dien je de Magento Composer Installer package als dependency op te geven in de composer.json van je extensie. De installer verwerkt onder andere de inhoud het modman bestand en weet op die manier welke bestanden bij jou extensie horen en waar deze geplaatst worden. Ten tweede kun je ook gebruik maken van de package.xml zoals die bij Magento Connect extensies zit. En tot slot, en meest omslachtige manier, kun je deze mapping in de composer.json zetten door de extra.map list te vullen. Je kunt voor uitgebreidere informatie over deze opties de blog van Magebase lezen.

Magento 2, Composer en Magento Marketplace

Binnenkort zal Magento een nieuwe “Magento Connect” lanceren met de naam Magento Marketplace. Via deze nieuwe Marketplace kan een Magento merchant direct extensies aanschaffen en worden deze automatisch gekoppeld aan een Magento account. Je geef Composer vervolgens toegang tot dit account waardoor hij automatisch kan zien welke extensies je aangeschaft hebt. Zo kan hij gemakkelijk kijken of er updates beschikbaar zijn, patches downloaden en direct installeren. Hoe dit in de praktijk zal werken moet nog blijken, maar het Magento 2 team is er al erg enthousiast over.

Help, wat een termen!

Het is inderdaad veel om in één keer te bevatten als je nog nooit met Composer hebt gewerkt. Kijk goed naar hoe andere Magento extensies het doen en lees je in. Het is de moeite zeker waard en zal er voor zorgen dat de ontwikkeling en deployment van je Magento 2 projecten een stuk gedirigeerder en robuuster wordt.
[widget id=”magereport_widget-5″ /]