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 :)
Přečteno 20 713×
Přečteno 18 551×
Přečteno 17 778×
Přečteno 17 524×
Přečteno 16 221×