Compositor para WordPress, Parte 2

Neste post, vou resumir o que comecei a compartilhar ontem: Usando as ferramentas e bibliotecas que compartilhei em conjunto com o Composer para farejar seus commits durante o desenvolvimento antes que o código chegue ao repositório.

Idealmente, você sempre desejará ver algo assim em seu terminal sempre que confirmar seu código:

Mas nem sempre é assim. Como acontece com a maioria das coisas, porém, quanto mais você praticar, mais você se acostumará a escrever código que passará automaticamente pelos vários sniffs implementados pelas diferentes regras (e suas personalizações).

Antes de fazer isso, porém, você precisa configurar o GrumPHP em seu repositório.

Compositor para WordPress: Sniffing Commits

Ontem, eu forneci um exemplo composer.json , então hoje vamos ver um exemplo de arquivo de configuração do GrumPHP e ver o que cada parte faz.

O importante a observar é que, embora parte do que você verá não seja atípico para um projeto, você pode ajustar isso o quanto quiser para cada projeto que usar. Às vezes você pode querer que seja mais focado do que é agora; outras vezes, você pode não se importar com alguns dos cheiros que ele oferece.

Uma configuração inicial

Dito isto, após a instalação do GrumPHP, ele criará um grumphp.ymlarquivo quase vazio que está pronto para ser configurado. Por exemplo, isto é o que você deve ver :

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

Observe que não há nada além de especificar:

• a localização do repositório,
• a localização dos binários instalados via Composer,
• as tarefas a executar.

Note que eu sempre usei ‘.’ para a localização do meu repositório porque nunca deixei de instalá-lo dentro do repositório que estou trabalhando.

O mesmo vale para os binários do Composer. Ou seja, depois de instalar tudo via Composer, deixo-os em seus locais iniciais.

E, finalmente, a tasksdiretiva inicial está vazia porque ainda não há nada para ser executado. Isso é o que eu estarei olhando na próxima etapa.

Configurando GrumPHP

Depois de instalar suas bibliotecas e estar pronto para configurar um pouco, talvez você possa fazer algo assim :

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

Não vou descrever tudo acima (porque não há muito o que delinear), mas ainda há algumas coisas a destacar:

• Observe que há uma lista de tarefas muito maior do que a definida no diretório inicial. Isso é normal e significa que queremos executar essas ferramentas usando a configuração padrão de cada uma dessas ferramentas.
• Algumas das regras têm um ~ao lado deles. Isso depende da tarefa em questão, mas geralmente significa que queremos usar a configuração padrão.
• Existem tarefas como as phpparserque têm subtarefas. Alguns deles, como você pode ver acima, usam o comportamento padrão. Outros optam por colocar na lista negra termos como die, var_dump, exite muito mais. Isso significa que, como se a diretiva não fosse clara o suficiente, faremos com que o GrumPHP falhe se alguma dessas instruções for detectada.
• Da mesma forma, dê uma olhada em phpmd. Isso aponta para o conjunto de regras que usaremos ao procurar várias bagunças no código. Nesse caso, ele aponta para um dist arquivo, mas pode apontar para qualquer conjunto personalizado de regras que você definiu.

Esta é apenas uma amostra do que você pode fazer com o GrumPHP. Ou seja, você pode instalar algumas bibliotecas via Composer, instalá-las e, em seguida, adaptar o GrumPHP para que você aproveite a funcionalidade fornecida.

Tal como acontece com outros projetos semelhantes, recomendo vivamente a leitura da documentação que existe para as várias tarefas que se integram com o GrumPHP.

Este é o Composer para WordPress?

Sim e não. Composer é um gerenciador de pacotes de propósito geral para projetos PHP; no entanto, parece que não vemos muito isso no mundo do WordPress. Isso não quer dizer que não é usado (é), mas simplesmente estar ciente do Composer e como usá-lo não é suficiente.

Em vez disso, acho importante saber como usar o Composer for WordPress para que possamos escrever o mais alto nível de código de qualidade possível, ao mesmo tempo em que garantimos que estamos aderindo aos padrões de codificação que também optamos por empregar .