Compositore per WordPress, parte 2

In questo post, concluderò ciò che ho iniziato a condividere ieri: utilizzare gli strumenti e le librerie che ho condiviso insieme a Composer per annusare i tuoi commit durante lo sviluppo prima che il codice raggiunga il repository.

Idealmente, vorrai sempre vedere qualcosa del genere nel tuo terminale ogni volta che esegui il commit del tuo codice:

Ma non è sempre così. Come per la maggior parte delle cose, però, più ti eserciti, più ti abituerai a scrivere codice che passerà automaticamente i vari sniff messi in atto attraverso le diverse regole (e le loro personalizzazioni).

Prima di farlo, però, devi configurare GrumPHP nel tuo repository.

Compositore per WordPress: Sniffing Commits

Ieri ho fornito un esempio composer.json , quindi oggi esamineremo un file di configurazione GrumPHP di esempio e vedremo cosa fa ogni parte.

La cosa importante da notare è che, sebbene parte di ciò che vedrai non sia atipico per un progetto, puoi perfezionarlo quanto vuoi per ogni progetto che usi. A volte potresti volere che sia più concentrato di quanto non lo sia ora; altre volte, potresti non preoccuparti di alcuni degli sniff che offre.

Una configurazione iniziale

Detto questo, dopo l’installazione di GrumPHP, creerà un grumphp.ymlfile quasi vuoto pronto per essere configurato. Ad esempio, questo è ciò che dovresti vedere :

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

Si noti che non c’è nient’altro che specificare:

• la posizione del deposito,
• la posizione dei binari installati tramite Composer,
• le attività da eseguire.

Nota che ho sempre usato ‘.’ per la posizione del mio repository perché non l’ho mai installato all’interno del repository su cui sto lavorando.

Lo stesso vale per i binari Composer. Cioè, dopo aver installato tutto tramite Composer, li lascio nelle loro posizioni iniziali.

E infine, la tasksdirettiva iniziale è vuota perché non c’è ancora nulla da eseguire. Questo è ciò che cercherò nel prossimo passaggio.

Configurazione di GrumPHP

Una volta che hai installato le tue librerie e sei pronto per configurare un po’ di configurazione, allora forse puoi fare qualcosa del genere :

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

Non delineerò tutto sopra (perché non c’è molto da delineare) ma ci sono ancora alcune cose da sottolineare:

• Si noti che esiste un elenco di attività molto più lungo di quello definito nella directory iniziale. È normale e significa che vogliamo eseguire quegli strumenti utilizzando la configurazione predefinita per ciascuno di questi strumenti.
• Alcune delle regole hanno un ~accanto a loro. Questo dipende dall’attività in questione, ma questo di solito significa che vogliamo utilizzare la configurazione predefinita.
• Ci sono attività come quelle phpparserche hanno attività secondarie. Alcuni di loro, come puoi vedere sopra, usano il comportamento predefinito. Altri scelgono di inserire nella lista nera termini come die, var_dump, exite altro. Ciò significa che, come se la direttiva non fosse sufficientemente chiara, causeremo il fallimento di GrumPHP se viene rilevata una di queste istruzioni.
• Allo stesso modo, dai un’occhiata a phpmd. Questo indica l’insieme di regole che useremo quando cercheremo vari pasticci nel codice. In questo caso, punta a un dist file ma può puntare a qualsiasi insieme personalizzato di regole che hai definito.

Questo è solo un esempio di ciò che puoi fare con GrumPHP. Cioè, puoi installare alcune librerie tramite Composer, installarle e quindi personalizzare GrumPHP in modo da sfruttare la funzionalità fornita.

Come per altri progetti simili, consiglio vivamente di leggere la documentazione esistente per le varie attività che si integrano con GrumPHP.

Questo è il compositore per WordPress?

Sì e no. Composer è un gestore di pacchetti generico per progetti PHP; tuttavia, non sembra che lo vediamo molto nel mondo di WordPress. Questo non vuol dire che non sia usato (lo è), ma semplicemente essere consapevoli di Composer e di come usarlo non è sufficiente.

Invece, penso che sia importante sapere come usare Composer per WordPress in modo da poter scrivere il più alto livello possibile di codice di qualità per tutto il tempo assicurandoci di aderire a qualsiasi standard di codifica che abbiamo anche scelto di impiegare .