Pokud jste vývojář softwaru, pak už pravděpodobně víte, že jednou z vašich mnoha rolí rozhodně není být dalším vynálezcem kola. Alespoň ne ve většině případů.
Rád bych napsal o JavaScript závislosti. Začněme však od začátku. Pokud jste softwarovým vývojářem, pak už asi víte, že jednou z vašich mnoha rolí rozhodně není být dalším vynálezcem kola. Alespoň ne ve většině případů. Svět pokročil natolik, že dnes existují balíčky téměř na všechno, které nám usnadňují a zefektivňují vývoj.
To samozřejmě není pobídkou ke ztrátě zájmu o jiné záležitosti - každý balíček má poměrně velký prostor pro zlepšení a vývoj. Nicméně vaším obchodním cílem je přinést kompletní produkt na talíři přesně na čas nebo ještě před jeho uplynutím. Balíčky vám pomohou tyto plány splnit a přinesou vám npm nebo příze na vrcholu seznamu nejlepších přátel, ale mějte na paměti, že každé řešení, stejně jako toto, může přinášet i rizika. A my se vám ho pokusíme popsat a ukázat lepší způsob, jak se z něj vyvléknout, v následujícím článku.
Začněme příběhem...
Představte si velký JavaScript projekt. Obchodní požadavek zavazuje vývojáře k použití konkrétního balíčku, který umožňuje správnou integraci s jiným systémem klienta. A to je zcela v pořádku. MVP byla dodána včas, byla podepsána další smlouva a vývoj pokračuje.. Klient požádá o integraci další části systému, která vyžaduje aktualizaci vašeho balíčku.
Tato část probíhá dobře, dokud se nevypálí testy. Zdá se, že balíček obsahuje jednoduchou, ale nepříjemnou chybu, která zatím nebyla opravena v žádné verzi produktu, a je známo, že se tak nestane dost brzy. Nemůžete jen tak opravit svůj node_modules adresář - měla by být z vašeho úložiště odstraněna ze sledování, takže se vaši spolupracovníci o vašich změnách nikdy nic nedozvědí! No, když už jste to četli, pravděpodobně jste už pochopili, co máte udělat - fork. Ale opravdu potřebujete takové kladivo?
Pochopení vašeho problému
Musíte si uvědomit, zda se problém, se kterým se potýkáte, bude týkat jen vás, nebo větší komunity. Někdy si lidé vykládají nedostatek určité funkce jako chybu, což není vždy správné. Proto, vaše řešení nemusí být komunitou přijato a zařazeno do oficiálního úložiště.. Stále ji však potřebujete tady a teď. Tak to pojďme zalátat!
Podle poznámek k vydání v repozitáři github, patch-package ) byl oficiálně vydán v květnu 2017. It je výkonný nástroj, který umožňuje instalaci modifikací uvnitř projektu závislostí do vašeho počítače. node_modules adresář. Někdo může říci, že je to docela šílenství - vypálení instalačního příkazu správce závislostí přepíše změny.
To je správně. Balíček záplat však koexistuje s balíčkem npm a příze dokonale (musím přiznat, že s npm to zatím funguje o něco lépe, více si můžete přečíst v části "Proč byste měli používat postinstall-prepare s Yarn?" v souboru README) a plně využívá přípravu skriptu ("script": {"prepare":""}) vaší package.json soubor. Patch-package doslova vytvoří rozdílový adresář mezi vašimi změnami a původním balíčkem, který je uložen ve složce patch vašeho aktuálního projektu..
Po spuštění příkazu install a stažení všech závislostí se tento rozdíl použije v adresáři projektu, čímž se dokonale zrekonstruují vaše změny pro všechny spolupracovníky. Usnadní vám to život, že? Řešení má i některé nevýhody. Balíček patch nemůže opravit závislosti vašeho balíčku ani provést žádné změny ve package.json.
V tomto případě můžete použít řešení s vidlicí. Rovněž je třeba zvážit počet změn, které se chystáte do balíčku závislostí aplikovat, a to, zda se budou časem zvětšovat. V případě, že ano - měli byste si použití forku dobře rozmyslet, protože se jedná o váš vlastní projekt.
Nebuďte sobečtí!
Patchování je skvělý způsob, jak opravit závislosti bez vytváření nekonečných forků a generování více zdrojových kódů projektu. Vždy byste však měli mít na paměti, že využívání výhod komunity by nemělo být jednosměrné. Pokud najdete chybu nebo máte pocit, že můžete vylepšit balík, který používáte, měli byste vždy zvážit pomoc ostatním registrací problému nebo dokonce přispěním do projektu!