Vlákno názorů ke článku PHP Jet vs Laravel od BoneFlute - Pozastavil bych se u toho composeru. Myslím si, že...

Pozastavil bych se u toho composeru.

Myslím si, že autor tento nástroj zle pochopil.

Jeden příklad za všechny: pokud mi guzzle vadí, tak si vytvořím vlastní odlehčené řešení (sám jsem to tak použil). A to dám jako balíček. Nikdo mě přece nenutí používat balíčky, které mi nepřijdou optimální.

Composer slouží k řešení situace, kdy máte desítky aplikací, a v každé chcete mít nějakou, klidně vlastní, knihovnu. Pomůže vám v tom, že v každém okamžiku budete vědět, v jakém stavu ta knihovna je. Tedy, nestane se vám, že v jedné aplikaci máte tu knihovnu patchnutou tak, v druhé jinak, ve třetí vůbec.

Composer řeší situaci, když pracujeme v týmu, a kolega dostane za úkol udělat über optimální a odlehčenou implementaci něčeho, a mě pak řekne, až bude mít hotovo. Nebudu si složitě stahovat jeho repo v nějaké verzi, a řešit jak requirovat jeho knihovny - protože toto je již standardizované.

Z tohoto důvodu jsou námitky autora bohužel liché.

Napadlo me to same. Composer je jen nastroj, pomoci ktereho je mozne udrzovat verze balicku (at uz cizich, tak vlastnich) v projektu, taky mi prisel pomerne nestastny priklad platebni brany ci guzzle, protoze to skutecne neni problem composeru, ale toho konkretniho balicku.

A ono to prece neplati jen pro balicky tretich stran, ale i pro framework jako takovy. Pokud bych se rozhodl Jet na svem projektu pouzit, tak predpokladam, ze se bude take casem vyvijet, budou se opravovat chyby, vydavat novejsi verze kompatibilni s novou verzi PHP, atd. Casem proste bude potreba udelat aktualizaci, protoze stara verze PHP uz nebude dostavat bezpecnostni aktualizace, a ja tak budu muset krome PHP upgradovat i framework. Jak udelam jeho aktualizaci na novejsi verzi ? Composer mi tohle jednoduse pomuze vyresit, bez composeru se takove veci resi dost tezko.

Nakonec i realny priklad - v jednom z minulych dilu mel kolega z komentaru problem s chybejici extension a verzi PHP. Pokud bych Jet instaloval pres composer, tak bych bylo i v definici composer.json jasne definovano, jakou verzi PHP a jake extensions framework ke svemu behu potrebuje. Nemohlo by se tak stat, ze mi instalace spadne na neznamem problemu, ale composer by mi okamzite a jasne sdelil co mi chybi.

To samozrejme nemeni nic na tom, ze autor do frameworku jiste vlozil hodne usili a casu, a za to ma rozhodne muj obdiv. Ale s vetsinou nazoru se bohuzel neztotoznuji

PS: jen tak pro zajimavost, nekolik pomerne velkych projektu, ktere udrzuji dodnes jedou na Zend Frameworku 1. Konkretne tedy na zf1-future forku, ktery je zpetne kompatibilni s puvodnim ZF1, zaroven ale bez problemu bezi na PHP 8.1. Predstava, ze bych mel Zend v kazdem projektu udrzovat sam, a distribuovat jej do vsech projektu bez composeru je skutecne desiva :)

Spíš jsem to špatně napsal.

Composer jako nástorj je fajn. Souhlas.

Vadím trend "nějak to poslepovat".
Ostatně Composer není jediný. PHP mělo a stále má PECL a PEAR.
A hlavně PECL jsem ve starších verzích PHP používal velice časti.

Tedy nic proti nástroji. Ale i dobrý nástroj se musí správně použít. A podle toho co jsem viděl je to někdy až extrémní. Viz to co píšu v článku.

Ale jak píše jiný kolega zde. Nad Composerem se ještě zamyslím ...

Díky za zpětnou vazbu.

Ja souhlasim s tim, ze "nejak to poslepovat" neni z pohledu aplikace idealni, nicmene moje zkusenost je takova, ze ten trend existoval vzdy, nemyslim si, ze by to byla zalezitost posledni doby. Ale ano, s tim, ze je ted k dispozici mnohem vice ruznych balicku je to asi viditelnejsi. Na druhou stranu jsou ty zavislosti alespon formalne zdokumentovane a nestava se, ze je jeden balicek v aplikaci nakopirovany trikrat v ruznych verzich, a kazda cast aplikace pouziva jinou :) Ale mozna mame jen jine zkusenosti, dost uz o tom

Jeste k PECLu - ten ja osobne nepovazuju za alternativu composeru (ani by byt nemel, protoze instaluje extensions napsane v C). Urcite se hodi na nektere konkretni veci, ktere je lepsi mit jako extension (pripadne je na tom zalozena jejich podstata, viz napr. Phalcon, myslim ze sveho casu experimentovali i s Twigem). Ale nelze jej brat jako alternativu composeru, je to nastroj, ktery ma jine vyuziti. Navic vyzaduje administratorsky pristup k serveru a musi extensions kompilovat primo na systemu, coz taky neni vzdycky mozne