Compositeur pour WordPress, partie 2

Dans cet article, je vais résumer ce que j’ai commencé à partager hier: utiliser les outils et les bibliothèques que j’ai partagés avec Composer pour sniffer vos commits pendant le développement avant que le code n’atteigne le référentiel.

Idéalement, vous voudrez toujours voir quelque chose comme ça dans votre terminal chaque fois que vous validerez votre code :

Mais ce n’est pas toujours le cas. Comme pour la plupart des choses, cependant, plus vous pratiquez, plus vous vous habituerez à écrire du code qui passera automatiquement les différents sniffs mis en place à travers les différentes règles (et leurs personnalisations).

Avant de faire cela, cependant, vous devez configurer GrumPHP dans votre référentiel.

Composer pour WordPress : renifler les commits

Hier, j’ai fourni un échantillon composer.json . Aujourd’hui, nous allons examiner un exemple de fichier de configuration GrumPHP et examiner ce que fait chaque partie.

La chose importante à noter est que bien que certains de ce que vous verrez ne soient pas atypiques pour un projet, vous pouvez affiner cela autant que vous le souhaitez pour chaque projet que vous utilisez. Parfois, vous voudrez peut-être qu’il soit plus ciblé qu’il ne l’est actuellement ; d’autres fois, vous ne vous souciez peut-être pas de certains des reniflements qu’il offre.

Une configuration initiale

Cela dit, une fois GrumPHP installé, il créera un grumphp.ymlfichier presque vide prêt à être configuré. Voici par exemple ce que vous devriez voir :

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

Notez qu’il n’y a rien d’autre que de spécifier:

• l’emplacement du dépôt,
• l’emplacement des binaires installés via Composer,
• les tâches à exécuter.

Notez que j’ai toujours utilisé ‘.’ pour l’emplacement de mon référentiel car je ne l’ai jamais installé dans le référentiel sur lequel je travaille.

Il en va de même pour les binaires Composer. C’est-à-dire qu’après avoir tout installé via Composer, je les laisse à leur emplacement initial.

Et enfin, la directive initiale tasksest vide car il n’y a encore rien à exécuter. C’est ce que je vais regarder dans la prochaine étape.

Configurer GrumPHP

Une fois que vous avez installé vos bibliothèques et que vous êtes prêt à configurer un peu, vous pouvez peut-être faire quelque chose comme ceci :

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

Je ne détaillerai pas tout ci-dessus (car il n’y a pas grand-chose à décrire) mais il y a encore quelques points à souligner :

• Notez qu’il existe une liste de tâches beaucoup plus longue que celle définie dans le répertoire initial. C’est normal, et cela signifie que nous voulons exécuter ces outils en utilisant la configuration par défaut pour chacun de ces outils.
• Quelques-unes des règles ont un ~à côté d’eux. Cela dépend de la tâche en question, mais cela signifie généralement que nous voulons utiliser la configuration par défaut.
• Il existe des tâches telles que celles phpparserqui ont des sous-tâches. Certains d’entre eux, comme vous pouvez le voir ci-dessus, utilisent le comportement par défaut. D’autres choisissent de mettre sur liste noire des termes tels que die, var_dump, exit, etc. Cela signifie que, comme si la directive n’était pas assez claire, nous ferons échouer GrumPHP si l’une de ces instructions est détectée.
• De même, jetez un œil à phpmd. Cela indique l’ensemble de règles que nous utiliserons lors de la recherche de divers désordres dans le code. Dans ce cas, il pointe vers un dist fichier mais peut pointer vers n’importe quel ensemble de règles personnalisé que vous avez défini.

Ceci n’est qu’un exemple de ce que vous pouvez faire avec GrumPHP. Autrement dit, vous pouvez installer certaines bibliothèques via Composer, les installer, puis personnaliser GrumPHP afin de tirer parti des fonctionnalités fournies.

Comme pour d’autres projets similaires, je recommande fortement de lire la documentation qui existe pour les différentes tâches qui s’intègrent à GrumPHP.

C’est Composer pour WordPress ?

Oui et non. Composer est un gestionnaire de packages à usage général pour les projets PHP. cependant, nous ne semblons pas le voir beaucoup dans le monde de WordPress. Cela ne veut pas dire qu’il n’est pas utilisé (il l’est), mais il ne suffit pas d’être conscient de Composer et de savoir comment l’utiliser.

Au lieu de cela, je pense qu’il est important de savoir comment utiliser Composer pour WordPress afin que nous puissions écrire le plus haut niveau de code de qualité possible tout en nous assurant que nous respectons les normes de codage que nous avons également choisi d’employer. .