Pierwsza pomoc dla uszkodzonych zależności JavaScript

Chciałbym napisać o JavaScript zależności. Zacznijmy jednak od początku. Jeśli jesteś programistą, to prawdopodobnie już wiesz, że jedną z wielu twoich ról zdecydowanie nie jest bycie kolejnym wynalazcą koła. Przynajmniej nie w większości przypadków. Świat poszedł na tyle do przodu, że dziś istnieją pakiety do prawie wszystkiego, dzięki czemu nasz rozwój jest łatwiejszy i bardziej wydajny.

Nie jest to oczywiście zachęta do utraty zainteresowania innymi kwestiami - każdy pakiet ma całkiem sporą przestrzeń do poprawy i ewolucji. Jednak celem biznesowym jest dostarczenie kompletnego produkt na talerzu na czas lub nawet przed jego upływem. Pakiety pomogą ci zrealizować te plany, przynosząc npm lub przędza na szczycie listy najlepszych przyjaciół, ale bądź świadomy: każde rozwiązanie, tak jak i to, może również nieść ze sobą ryzyko. A my postaramy się je opisać i pokazać lepszy sposób na uniknięcie go w poniższym artykule.

Zacznijmy od historii...

Wyobraźmy sobie duży JavaScript projekt. Wymagania biznesowe zobowiązują programistów do korzystania z określonego pakietu, umożliwiającego odpowiednią integrację z innym systemem klienta. I to jest całkowicie w porządku. MVP została dostarczona na czas, podpisano kolejną umowę i rozwój jest kontynuowany. Klient prosi o integrację kolejnej części systemu, która wymaga aktualizacji pakietu.

Ta część idzie dobrze, dopóki nie zostaną uruchomione testy. Wygląda na to, że pakiet zawiera prosty, ale niewygodny błąd, który nie został jeszcze naprawiony w żadnym wydaniu produktu i wiadomo, że nie nastąpi to wystarczająco szybko. Nie można po prostu naprawić node_modules katalog - powinien zostać usunięty z repozytorium ze śledzenia, dzięki czemu Twoi współpracownicy nigdy nie dowiedzą się o Twoich zmianach! Cóż, kiedy to czytałeś, prawdopodobnie już zrozumiałeś, co należy zrobić - rozwidlić. Ale czy naprawdę potrzebujesz takiego młotka?

Zrozumienie problemu

Musisz być świadomy, czy problem, z którym się borykasz, będzie dotyczył tylko Ciebie, czy większej społeczności. Czasami ludzie interpretują brak pewnej funkcjonalności jako błąd, co nie zawsze jest poprawne. Dlatego, Twoje rozwiązanie może nie zostać zaakceptowane przez społeczność i nie zostać włączone do oficjalnego repozytorium.. Jednak nadal potrzebujesz go tu i teraz. Cóż, załatajmy to!

Zgodnie z informacjami o wydaniu repozytorium github, patch-package ) została oficjalnie wydana w maju 2017 roku. It jest potężnym narzędziem, które pozwala na modyfikacje wewnątrz projektu zależności, aby być zainstalowanym w twoim node_modules katalog. Niektórzy mogą powiedzieć, że to szaleństwo - odpalenie polecenia install w menedżerze zależności spowoduje nadpisanie zmian.

Cóż, to prawda. Jednak pakiet poprawek współistnieje z npm i przędza doskonale (muszę przyznać, że jak dotąd działa nieco lepiej z npm, możesz przeczytać więcej w sekcji "Dlaczego powinieneś używać postinstall-prepare z Yarn?" w pliku README) i w pełni wykorzystuje przygotowanie skryptu ("script": { "prepare":""}) twojego package.json plik. Patch-package dosłownie tworzy katalog różnic między wprowadzonymi zmianami a oryginalnym pakietem, przechowywany w folderze poprawek rzeczywistego projektu.

Po uruchomieniu polecenia install i pobraniu wszystkich zależności, stosuje tę różnicę do katalogu projektu, tworząc idealną rekonstrukcję zmian dla wszystkich współpracowników. Ułatwia to życie, prawda? Rozwiązanie to ma również pewne wady. Patch-package nie może naprawić zależności twojego pakietu ani wprowadzić żadnych zmian w package.json.

W takim przypadku można użyć rozwiązania fork. Musisz również wziąć pod uwagę liczbę zmian, które zamierzasz zastosować w swoim pakiecie zależności i czy będą one rosły w czasie. W przypadku, gdy tak się stanie - powinieneś dokładnie przemyśleć użycie forka, ponieważ jest to twój własny projekt.

Nie bądź samolubny!

Patchowanie to świetny sposób na naprawienie zależności bez tworzenia niekończących się forków i generowania wielu źródeł projektu. Należy jednak zawsze pamiętać, że korzystanie ze społeczności nie powinno być jednokierunkowe. Jeśli znajdziesz błąd lub czujesz, że możesz ulepszyć pakiet, którego używasz, zawsze powinieneś rozważyć pomoc innym, rejestrując problem lub nawet wnosząc swój wkład w projekt!