Lepszy kod WordPress: plik blokady Composer
Zanim zakończymy naszą dyskusję na temat Composera, pozostała nam jedna ważna rzecz do omówienia: katalog dostawcy (i co za tym idzie, plik blokady Composera).
W szczególności musimy porozmawiać o tym, dlaczego nie musimy zatwierdzać katalogu dostawcy do repozytorium, ale o tym, jak nasi współpracownicy mogą być pewni, że mają najnowszą wersję oprogramowania potrzebnego do pracy z naszą bazą kodu.
Używanie narzędzi jakości kodu do pisania lepszego kodu WordPress jest ważne, tak, ale ważne jest również zrozumienie, jak prawidłowo zarządzać zależnościami i naszym repozytorium. Więc zanim przyjrzymy się wspomnianym narzędziom, przejrzyjmy plik blokady, rolę, jaką odgrywa i dlaczego nie musimy zatwierdzać katalogu dostawcy w naszym repozytorium.
Lepszy kod WordPress z plikiem blokady Composer
Dla tych, którzy pracują z WordPressem – i być może z innymi frameworkami i podstawami opartymi na PHP (tak naprawdę nie wiem, ponieważ zwykle nie pracuję z nimi) – polegają na Composer, co jest dobrą rzeczą.
Może to również prowadzić do chęci zatwierdzenia całej kontroli źródła katalogu dostawcy, co nie jest dobrą rzeczą.
Jak wspomniano w poprzednim poście :
I nie polecam sprawdzania katalogu dostawców w twoim repozytorium. Może to stać się później ogromnym katalogiem i może podważyć cały cel Composera.
Jak więc możemy upewnić się, że nie niepotrzebnie zatwierdzamy plików (a tym samym powiększamy rozmiar naszego repozytorium) do repozytorium, jednocześnie upewniając się, że nasi współtwórcy używają tej samej wersji oprogramowania co my?
Chęć zatwierdzenia katalogu dostawców
Dla tych z was, którzy uruchomili Composer i są zaznajomieni z przynajmniej przeglądaniem katalogu dostawcy, prawdopodobnie przywykli do oglądania wielu katalogów zależności, które są zainstalowane.
I są przydatne; w przeciwnym razie byś ich nie uwzględnił, prawda?
Ale oto kwestia katalogu dostawcy : nawet jeśli masz tylko kilka zależności zainstalowanych w swoim projekcie, sam rozmiar pliku może być duży. A to może być jeszcze większe, gdy masz dużo zależności.
Niezależnie od tego, przekazanie tego do kontroli źródła wydaje się mieć sens, prawda? Chcemy mieć pewność, że wszyscy mają tę samą wersję oprogramowania, której używamy, i chcemy mieć pewność, że nie będą musieli zajmować się Composerem.
Jest jednak inny sposób. Dzięki temu nasze repozytorium jest małe, jednocześnie upewniając się, że wersje naszych zależności są zsynchronizowane z tymi, którzy klonują repozytorium, zatwierdzają repozytorium lub dla dowolnego narzędzia do ciągłej integracji, które korzysta z repozytorium.
Zrozumienie pliku blokady
Zanim omówię katalog dostawców, chciałbym poruszyć inny ważny aspekt Composera: plik blokady. Oznacza to, że jeśli uruchomisz polecenie instalacji lub aktualizacji w swoim terminalu, zobaczysz plik blokady wygenerowany wraz z katalogiem dostawcy .
Co to za plik?
Poprzedni post pokazał przykładowy plik konfiguracyjny. Jedną z rzeczy, na które pozwala nam ten plik, jest definiowanie zewnętrznych bibliotek lub zależności, których możemy używać w naszych projektach.
Mówiłem o tym w innych postach (możemy przyjrzeć się temu nieco dalej w tej serii). Ale tutaj pojawia się plik blokady.
Krótko mówiąc, plik blokady zawsze zawiera informacje o wersji – dokładnej wersji – zależności używanych w projekcie podczas ostatniego uruchomienia instalacji lub aktualizacji.
Po zakończeniu instalacji Composer zapisuje wszystkie pakiety i ich dokładne wersje, które pobrał do pliku composer.lock, blokując projekt w tych konkretnych wersjach.
Powinieneś zatwierdzić plik composer.lock do swojego repozytorium projektu, aby wszystkie osoby pracujące nad projektem były zablokowane do tych samych wersji zależności (więcej poniżej).
Celem jest upewnienie się, że każdy z nich korzysta z tej samej wersji zależności projektu – nie starsze wersje, nie nowsze wersje – ale ta sama wersja.
Tak więc, po uruchomieniu kompozytora instalacji, gdy plik blokady jest zawarty w repozytorium, użyje wersji oprogramowania określonej w pliku blokady.
Gwarantuje to, że wszyscy korzystają z tej samej wersji każdej zależności, a tym samym mogą zapobiec konieczności zatwierdzania katalogu dostawcy do kontroli źródła.
Pisanie kodu wyższej jakości
Więc dokąd stąd pójdziemy?
Teraz, gdy rozumiemy, jak korzystać z Composera i jak korzystać z pliku blokady, możemy zacząć mówić o rzeczywistych zależnościach, które pomagają poprawić jakość naszego kodu.
A kiedy mówimy o pisaniu kodu o wyższej jakości, istnieją narzędzia stworzone właśnie do tego. Dlatego w kilku następnych postach przyjrzymy się niektórym z nich.