Composer balíčky vytvářející soubory mimo vendor/ rubrika: Programování: PHP

Anonym
položil/-a 7.5.2018
 
upravil/-a 7.5.2018

Ahoj,
zajímal by mě Váš názor na to, že composer balíčky si vytváří některé soubory mimo vendor. Samotný balíček je standardně ve vendor/<..>/<..>, ale klidně si vygeneruje třídy do app/model (v rootu projektu, Nette) apod. Je to podle Vás ok nebo bad practice?

Díky

odkaz
9 Taco
odpověděl/-a 8.5.2018

Composer je nástroj, který poskytuje třídy a funkce. Jeho svět končí na hranici autoload.php. Nikam jinam by neměl vidět. Pokud nějaký balíček poskytuje další zdroje, krom php, jako třeba css, nebo js, tak by měli být k dispozici v tom balíčku. Pokud je někdo chce, šáhne si na ně tam. Kam se stahují balíčky je definováno v composer.json. A opět, balíčky sami o tom nemají tušení.

Pokud balíček z composeru začne šahat ven, třeba vytvářet temp, var, nebo kopírovat něco do app/model, začne vznikat obousměrná závislost. Najednou už není composer jen zdroj knihoven. Začne se plést do buildu, začne vyžadovat existenci různých adresářů (temp, var, app/model). Já třeba nemám vždycky aplikaci v app. Někdy ji mám v libs, někdy v source. A někdy to tak být i musí. Začne to být celé (podle mě zbytečně) složitější. Jak na pochopení, tak na používání a chybovost a svědomitost autorů balíčků.

Jako prof of concept dobrý, ale v praxi bych to nechtěl.

Komentáře

  • Anonym : Díky za komentář. Dá se říct, že nad tím přemýšlím stejně. V mém případě mi chování composer install/update přijde až příliš magické - řeší věci od kopírování skeleton souborů do projektu, přes práci s gitem, nastavení oprávnění temp složek až po drobné úpravy v .neon nebo .php souborech.. Je za tím chválihodná snaha maximálně automatizovat a usnadnit práci všem v teamu, ale u mě je to spíš zdrojem frustrace. Dost z těch scriptů je vázaných na prostředí na vývojovém serveru, přenositelnost 0. Chci o tom ve firmě kde pracuji otevřít diskuzi, tak hledám argumenty. 11.5.2018
  • Taco : Zdůraznil bych, že v případě (klasického) použití composeru jde o metodu pull. Tedy, composer něco zajistí, a vytvoří konzistentní prostředí, a ty si z něho hrabeš. Opakem je, když by composer tlačil něco pomocí push. To se pak mnohem hůř hlídá a naopak snadněji rozbíjí. Pokud někdo chce od composeru víc, tak ať z toho udělá balíček, a jádro aplikace si pro to šáhne. To je ideální maximum, který se mi osvědčil. 11.5.2018

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.