Kompozytor dla WordPressa, część 2

W tym poście podsumuję to, czym zacząłem się wczoraj dzielić: Używanie narzędzi i bibliotek, które udostępniłem w połączeniu z Composerem, do sniffowania twoich zatwierdzeń podczas rozwoju, zanim kod trafi do repozytorium.

W idealnym przypadku zawsze będziesz chciał widzieć coś takiego w swoim terminalu za każdym razem, gdy zatwierdzisz swój kod:

Ale nie zawsze tak jest. Podobnie jak w przypadku większości rzeczy, im więcej ćwiczysz, tym bardziej przyzwyczaisz się do pisania kodu, który automatycznie przekaże różne sniffy wprowadzone przez różne reguły (i ich dostosowania).

Jednak zanim to zrobisz, musisz skonfigurować GrumPHP w swoim repozytorium.

Kompozytor dla WordPressa: Sniffing Commits

Wczoraj dostarczyłem próbkę composer.json , więc dzisiaj przyjrzymy się przykładowemu plikowi konfiguracyjnemu GrumPHP i przyjrzymy się, co robi każda część.

Należy zauważyć, że chociaż niektóre z tego, co zobaczysz, nie są nietypowe dla projektu, możesz dostroić to tak bardzo, jak chcesz dla każdego używanego projektu. Czasami możesz chcieć, aby był bardziej skoncentrowany niż jest teraz; innym razem możesz nie dbać o niektóre z oferowanych przez nią wąchów.

Konfiguracja początkowa

To powiedziawszy, po zainstalowaniu GrumPHP utworzy prawie pusty grumphp.ymlplik, który jest gotowy do skonfigurowania. Na przykład oto, co powinieneś zobaczyć :

parameters:
    git_dir:. bin_dir: vendor/bin
    tasks:

Zauważ, że nie ma nic poza określeniem:

• lokalizacja repozytorium,
• lokalizacja plików binarnych zainstalowanych przez Composer,
• zadania do uruchomienia.

Zauważ, że zawsze używałem „." dla lokalizacji mojego repozytorium, ponieważ nigdy nie instalowałem go w repozytorium, w którym pracuję.

To samo dotyczy plików binarnych Composer. Oznacza to, że po zainstalowaniu wszystkiego przez Composer zostawiam je w ich początkowych lokalizacjach.

I wreszcie, początkowa tasksdyrektywa jest pusta, ponieważ nie ma jeszcze nic do uruchomienia. Na to będę się przyglądał w następnym kroku.

Konfiguracja GrumPHP

Gdy masz już zainstalowane biblioteki i jesteś gotowy do konfiguracji, być może możesz zrobić coś takiego :

parameters:
    git_dir:. bin_dir: vendor/bin
    tasks:
      securitychecker:
      composer:
      jsonlint:
      xmllint:
      yamllint:
      phpstan:
      phplint:
      phpunit:
      phpcs:
      phpcpd:
      phpmnd:
      phpparser:
        visitors:
          no_exit_statements: ~
          never_use_else: ~
          forbidden_function_calls:
            blacklist:
              - "die"
              - "var_dump"
              - "exit"
      phpversion:
        project: '7.0'
       phpmd:
         ruleset: ['phpmd.xml.dist']

Nie będę opisywać wszystkiego powyżej (ponieważ nie ma wiele do nakreślenia), ale wciąż jest kilka rzeczy do podkreślenia:

• Zauważ, że istnieje znacznie dłuższa lista zadań niż ta, która została zdefiniowana w początkowym katalogu. To normalne i oznacza to, że chcemy uruchomić te narzędzia przy użyciu domyślnej konfiguracji dla każdego z tych narzędzi.
• Kilka zasad ma ~obok siebie. Zależy to od zadania, o którym mowa, ale zwykle oznacza to, że chcemy użyć domyślnej konfiguracji.
• Są takie zadania, phpparserktóre mają podzadania. Niektóre z nich, jak widać powyżej, korzystają z zachowania domyślnego. Inni wybierają terminy na czarnej liście, takie jak die, var_dump, exiti inne. Oznacza to, że tak jakby dyrektywa nie była wystarczająco jasna, spowodujemy, że GrumPHP nie powiedzie się, jeśli którakolwiek z tych instrukcji zostanie wykryta.
• Podobnie spójrz na phpmd. Wskazuje to na zestaw reguł, których użyjemy, szukając różnych bałaganów w kodzie. W tym przypadku wskazuje na dist plik, ale może wskazywać na dowolny niestandardowy zestaw reguł, który zdefiniowałeś.

To tylko próbka tego, co możesz zrobić z GrumPHP. Oznacza to, że możesz zainstalować niektóre biblioteki przez Composer, zainstalować je, a następnie dostosować GrumPHP tak, aby wykorzystać jego funkcjonalność.

Podobnie jak w przypadku innych podobnych projektów, gorąco polecam przeczytanie dokumentacji, która istnieje dla różnych zadań, które integrują się z GrumPHP.

To jest Kompozytor dla WordPressa?

Tak i nie. Composer to menedżer pakietów ogólnego przeznaczenia dla projektów PHP; jednak wydaje się, że nie widzimy tego zbyt często w świecie WordPressa. Nie oznacza to, że nie jest on używany (jest), ale samo bycie świadomym Composera i tego, jak go używać, nie wystarczy.

Zamiast tego uważam, że ważne jest, aby wiedzieć, jak korzystać z Composera dla WordPressa, abyśmy byli w stanie pisać kod o najwyższej możliwej jakości, jednocześnie upewniając się, że przestrzegamy wszelkich standardów kodowania, które również zdecydowaliśmy się zastosować .