WordPressi helilooja, 2. osa

Selles postituses võtan kokku selle, mida ma eile jagama hakkasin: kasutades tööriistu ja teeke, mida olen koos Composeriga jaganud, et nuusutada arenduse ajal tehtud kohustusi enne, kui kood hoidlasse jõuab.

Ideaalis soovite alati oma terminalis näha midagi sellist, kui sisestate oma koodi:

Kuid see pole alati nii. Nagu enamiku asjade puhul, mida rohkem harjutate, seda rohkem harjute kirjutama koodi, mis edastab automaatselt erinevad reeglid (ja nende kohandused) tehtud nuusutused.

Enne seda peate siiski oma hoidlas konfigureerima GrumPHP.

Helilooja WordPressile: Sniffing Commits

Eile esitasin näidise composer.json , nii et täna vaatame GrumPHP konfiguratsioonifaili näidist ja vaatame, mida iga osa teeb.

Oluline on märkida, et kuigi osa sellest, mida näete, ei ole projekti jaoks ebatüüpiline, saate seda iga kasutatava projekti puhul nii palju kui soovite. Mõnikord võite soovida, et see oleks rohkem keskendunud kui praegu; muul ajal ei pruugi te mõnest selle pakutavast nuusutamisest hoolida.

Esialgne konfiguratsioon

See tähendab, et pärast GrumPHP installimist loob see peaaegu tühja grumphp.ymlfaili, mis on konfigureerimiseks valmis. Näiteks peaksite nägema seda :

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

Pange tähele, et sellel pole muud kui täpsustada:

• hoidla asukoht,
• Composeri kaudu installitud binaarfailide asukoht,
• ülesandeid, mida täita.

Pange tähele, et olen alati kasutanud "." oma hoidla asukoha jaoks, sest ma pole seda kunagi installinud hoidlasse, kus ma töötan.

Sama kehtib ka helilooja binaarfailide kohta. See tähendab, et pärast selle installimist Composeri kaudu jätan need algsesse asukohta.

Ja lõpuks on esialgne taskskäskkiri tühi, sest tegelikult pole veel midagi käivitada. Seda ma järgmises etapis vaatlen.

GrumPHP seadistamine

Kui olete oma teegid installinud ja olete valmis veidi konfigureerima, saate ehk teha midagi sellist :

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

Ma ei hakka kõike ülalpool kirjeldama (sest seal pole palju visandada), kuid siiski on mõned asjad, millele tähelepanu pöörata:

• Pange tähele, et ülesannete loend on palju pikem kui algses kataloogis määratletud. See on normaalne ja see tähendab, et tahame neid tööriistu käitada, kasutades kõigi nende tööriistade vaikekonfiguratsiooni.
• Mõned reeglid on nende ~kõrval. See sõltub kõnealusest ülesandest, kuid tavaliselt tähendab see, et soovime kasutada vaikekonfiguratsiooni.
• On selliseid ülesandeid, phpparsermillel on alamülesanded. Mõned neist, nagu eespool näete, kasutavad vaikekäitumist. Teised valivad sellised terminid nagu die, var_dump, exitja muud musta nimekirja. See tähendab, et nagu poleks direktiiv piisavalt selge, põhjustame GrumPHP ebaõnnestumise, kui mõni neist väidetest tuvastatakse.
• Samamoodi vaadake phpmd. See viitab reeglistikule, mida kasutame koodis erinevate jamade otsimisel. Sel juhul osutab see dist failile, kuid võib osutada mis tahes kohandatud reeglistikule, mille olete määratlenud.

See on vaid näide sellest, mida saate GrumPHP-ga teha. See tähendab, et saate installida mõned teegid Composeri kaudu, need installida ja seejärel GrumPHP-d kohandada, et saaksite selle pakutavaid funktsioone ära kasutada.

Nagu ka teiste sarnaste projektide puhul, soovitan tungivalt lugeda dokumentatsiooni, mis on olemas erinevate GrumPHP-ga integreeritavate ülesannete kohta.

Kas see on WordPressi helilooja?

Jah ja ei. Composer on PHP-projektide üldotstarbeline paketihaldur; näib aga, et me WordPressi maailmas seda eriti ei näe. See ei tähenda, et seda ei kasutata (on), vaid sellest, et olla teadlik Composerist ja selle kasutamisest, ei piisa.

Selle asemel arvan, et on oluline teada, kuidas kasutada Composerit WordPressi jaoks, et saaksime kirjutada võimalikult kõrge kvaliteediga koodi, tagades samal ajal, et järgime mis tahes kodeerimisstandardeid, mida oleme samuti valinud. .