Kompositör för WordPress, del 2

I det här inlägget ska jag sammanfatta det jag började dela med mig av igår: Använda verktygen och biblioteken jag har delat i samband med Composer för att sniffa dina commits under utvecklingen innan koden träffar förvaret.

Helst kommer du alltid att vilja se något sånt här i din terminal när du anger din kod:

Men så är det inte alltid. Men som med de flesta saker, ju mer du övar, desto mer vänjer du dig vid att skriva kod som automatiskt kommer att passera de olika sniffarna som införts genom de olika reglerna (och deras anpassningar).

Innan du gör det måste du dock konfigurera GrumPHP i ditt arkiv.

Kompositör för WordPress: Sniffing Commits

Igår tillhandahöll jag ett prov composer.json så idag ska vi titta på ett exempel på en GrumPHP-konfigurationsfil och titta på vad varje del gör.

Det viktiga att notera är att även om en del av det du kommer att se inte är atypiskt för ett projekt, kan du finjustera detta så mycket du vill för varje projekt du använder. Ibland kanske du vill att det ska vara mer fokuserat än det är nu; andra gånger kanske du inte bryr dig om några av sniffarna som den erbjuder.

En initial konfiguration

Som sagt, efter att GrumPHP har installerats, kommer det att skapa en nästan tom grumphp.ymlfil som är redo att konfigureras. Det här är till exempel vad du bör se :

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

Observera att det inte är något annat än att specificera:

• platsen för förvaret,
• platsen för binärfilerna installerade via Composer,
• uppgifterna att köra.

Observera att jag alltid har använt ‘.’ för platsen för mitt arkiv eftersom jag aldrig har installerat det i arkivet som jag arbetar.

Detsamma gäller för Composer-binärfilerna. Det vill säga, efter att jag installerat allt via Composer, lämnar jag dem på deras ursprungliga platser.

Och slutligen, det ursprungliga tasksdirektivet är tomt eftersom det faktiskt inte finns något att köra ännu. Det är vad jag kommer att titta på i nästa steg.

Konfigurera GrumPHP

När du väl har installerat dina bibliotek och är redo att ställa in lite konfiguration, kanske du kan göra något så här :

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']

Jag kommer inte att beskriva allt ovan (eftersom det inte finns mycket att beskriva) men det finns fortfarande några saker att påpeka:

• Observera att det finns en mycket längre lista med uppgifter än vad som definierades i den ursprungliga katalogen. Det är normalt, och det betyder att vi vill köra dessa verktyg med standardkonfigurationen för vart och ett av dessa verktyg.
• Några av reglerna har en ~bredvid sig. Detta beror på uppgiften i fråga, men det betyder vanligtvis att vi vill använda standardkonfigurationen.
• Det finns sådana uppgifter som phpparserhar deluppgifter. Vissa av dem, som du kan se ovan, använder standardbeteende. Andra väljer att svartlista termer som die, var_dump, exit, och mer. Det betyder, som om direktivet inte var tillräckligt tydligt, att vi kommer att få GrumPHP att misslyckas om något av dessa uttalanden upptäcks.
• På samma sätt, ta en titt på phpmd. Detta pekar på uppsättningen regler som vi kommer att använda när vi letar efter olika röror i koden. I det här fallet pekar den på en dist fil men kan peka på alla anpassade regler som du har definierat.

Det här är bara ett exempel på vad du kan göra med GrumPHP. Det vill säga, du kan installera vissa bibliotek via Composer, installera dem och sedan skräddarsy GrumPHP så att du drar nytta av den funktionalitet det tillhandahålls.

Som med andra liknande projekt rekommenderar jag starkt att läsa dokumentationen som finns för de olika uppgifterna som integreras med GrumPHP.

Detta är Composer för WordPress?

Ja och nej. Composer är en generell pakethanterare för PHP-projekt; vi verkar dock inte se det mycket i WordPress-världen. Detta betyder inte att det inte används (det är det), men att bara vara medveten om Composer och hur man använder den är inte tillräckligt.

Istället tror jag att det är viktigt att veta hur man använder Composer för WordPress så att vi kan skriva högsta möjliga kvalitetskod samtidigt som vi ser till att vi följer de kodningsstandarder vi också har valt att använda .