Widgets do WordPress: Refatoração, Parte 6

Você deve ser bem versado na refatoração que estamos fazendo em relação ao WordPress Widget Boilerplate. Se não, eu recomendo acompanhar a série até agora por:

• lendo o post anterior ,
• ou lendo a série inteira até este ponto,
• e olhando para o ramo de desenvolvimento do projeto no GitHub.

No que diz respeito à base de código, estamos em um bom lugar agora. Começamos a refatorar grande parte do código em classes menores e mais focadas. E acabamos de configurar um Registro para que possamos começar a trabalhar com instâncias de objetos em todo o plugin sem a necessidade de muito acoplamento.

Mas ainda há um problema que estamos enfrentando e trata de namespaces e carregamento automático. Eu falei um pouco sobre isso alguns anos atrás, mas não no que se refere ao Composer.

E é isso que vamos ver neste post.

The WordPress Widget Boilerplate: Refatoração, Parte 6

No segundo post desta série, começamos a falar sobre o Composer. Se você perguntar à maioria dos desenvolvedores PHP (incluindo aqueles que trabalham no WordPress), provavelmente ouvirá que o Composer é um gerenciador de pacotes ou um gerenciador de dependências.

Resumindo, é uma forma de trazermos bibliotecas de terceiros para nosso projeto e então utilizarmos seus recursos (para que não tenhamos que escrever nosso próprio código para isso).

Mas há outro recurso que o Composer oferece que é de imensa utilidade, especialmente quando você está usando muitas classes e não deseja usar instruções require_once em toda a sua base de código.

E esse é o carregador automático.

O Autoloader Definido

Direto do manual:

Para bibliotecas que especificam informações de carregamento automático, o Composer gera um vendor/autoload.phparquivo. Você pode simplesmente incluir este arquivo e começar a usar as classes que essas bibliotecas fornecem sem nenhum trabalho extra:

Se você acompanhou o código até agora, verá que já estamos usando o autoloader gerado pelo Composer.

Primeiro, definimos a configuração necessária :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Então começamos a incluí-lo no bootstrap do plugin (que finalizaremos hoje):

Mas há um problema aqui: como carregamos apenas as classes que precisamos para distribuição?

Colocando de outra forma: há muitas bibliotecas que estamos usando no desenvolvimento para garantir que estamos escrevendo código de alta qualidade e compatível com os padrões. Mas não queremos distribuir 10 MB de dados para quem usa nosso projeto.

Em vez disso, precisamos incluir apenas os arquivos necessários, certo? E para fazer isso, precisamos ter certeza de que geramos um autoloader que possamos incluir e que faça exatamente isso.

Primeiro, mostrarei o comando e explicarei o que ele faz:

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Isso gerará exatamente o que precisamos para que nosso projeto funcione em um ambiente de produção. Veja o que cada sinalizador faz:

• instalação do compositor. Isso simplesmente instala todas as dependências. Se você já tiver vários deles em seu diretório de fornecedores, isso removerá todos, exceto aqueles que são necessários.
• não-dev. Isso evitará que o Composer instale os pacotes na seção require-dev de seus arquivos de configuração (ou seja, dependências que estamos usando com o GrumPHP).
• não-ansi. Isso evita que qualquer saída ANSI ocorra. Você pode não se importar em executar isso ou não. Se você optar por fazer algum tipo de implantação automática, use-o; caso contrário, ele pode ser omitido do comando.
• sem interação. Esse é outro sinalizador usado especificamente para ambientes nos quais você deseja construir o projeto automaticamente e não precisa se envolver com perguntas, saídas e coisas assim.
• otimizar-autoloader. Em suma, isso gera um autoloader mais rápido. Pode demorar um pouco para ser executado, dependendo do tamanho do seu projeto, mas compensa na hora de iniciar seu trabalho.
• sem progresso. Isso oculta a exibição da barra de progresso no terminal. Você pode realmente querer ver isso e, em caso afirmativo, isso é ótimo; no entanto, alguns ambientes podem não lidar bem com determinados caracteres (como backspace).
• prefer-dist. Isso garantirá que os pacotes instalados sejam feitos usando a versão de distribuição (em vez de algo menos estável).

Ainda interessado?

Se você está realmente curioso sobre como otimizar o autoloader para projetos fora deste post, recomendo ler esta página na documentação do Composer. Está fora do escopo do que estamos fazendo aqui, mas pode ser útil com outros trabalhos que você tem agora ou que fará no futuro.

Como é essa aparência no Boilerplate?

Se você estiver trabalhando no Boilerplate em sua máquina local, poderá ver algo assim:

Mas se você executar o comando incluído acima, verá algo assim:

Essa é uma grande diferença e este é um projeto pequeno. Imagine fazer algo muito maior que será executado em produção.

Falando por experiência própria, posso dizer que os projetos podem atingir rapidamente 20 MB ou mais de dependências se você estiver usando uma variedade de bibliotecas de terceiros para coisas como log, solicitações HTTP e ferramentas de qualidade de código.

Incluiremos em nosso diretório de fornecedores?

As pessoas costumam dizer que você não deve incluir o diretório do fornecedor no controle de origem e por um bom motivo: pode ser enorme.

Até a documentação do Composer fala sobre isso:

A melhor prática é fazer com que todos os desenvolvedores usem o Composer para instalar as dependências. Da mesma forma, o servidor de compilação, CI, ferramentas de implantação, etc., devem ser adaptados para executar o Composer como parte da inicialização do projeto.

então o que devemos fazer? Precisamos do autoloader e precisamos de certas dependências porque nossos usuários não saberão rodar (nem deveriam rodar!) Composer sempre que baixarem nosso trabalho.

Por causa da natureza do WordPress e do trabalho que estamos fazendo, precisaremos confirmar o diretório do fornecedor, mas apenas com certos requisitos.

1. Criaremos uma ramificação que será usada para lançamento (chamaremos criativamente de lançamento e podemos mesclar o desenvolvimento sempre que necessário).
2. Garantiremos que o diretório do fornecedor não faça parte do arquivo gitignore; no entanto, nos certificaremos de que os diretórios .git dentro do diretório do fornecedor sejam ignorados (isso ainda pode ocupar muito espaço).

Então vamos fazer cada passo e ver como fica quando terminarmos.

Criando a ramificação de lançamento

Para criar uma nova ramificação de dentro do terminal, digite o seguinte comando :

$ git checkout -b release

Isso pegará todo o código no qual estamos trabalhando e criará uma nova ramificação com ele. Já que este será o branch que usaremos para atuar como o que nossos usuários irão usar (falaremos sobre master em um post futuro).

Primeiro, revise seu arquivo composer.json e verifique se ele inclui o seguinte:

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

Agora precisamos ter certeza de que executamos o comando Composer acima para garantir que nada além do que precisamos esteja no diretório do fornecedor.

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Agora precisamos atualizar o gitignore.

Atualizando o que ignoramos

E se você acompanhou a série e o post até aqui, sabe que será algo assim (pode incluir mais ou menos, mas deve incluir pelo menos isso).

Para mim, isso se parece com o seguinte :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

Dependendo se você estiver usando um terminal ou um cliente, verá que há novos arquivos para confirmar (do diretório do fornecedor, especificamente). Portanto, adicione-os ao seu branch.

Em seguida, confirme suas alterações. Você pode ter que especificar o seguinte se estiver trabalhando no terminal:

$ git push --set-upstream origin release

E com isso, seu código deve funcionar e estar disponível no GitHub (ou em qualquer serviço de controle de origem que você esteja usando). Você pode ver o que tenho disponível aqui.

Adicionando Funcionalidade

Agora que temos todas as peças necessárias no lugar, é hora de começar a usar o Composer, o autoloader, nossas classes abstratas e nosso Registry para começar a adicionar algumas funcionalidades básicas ao WordPress Widget Boilerplate para que tenhamos algo para mostrar em nosso trabalho .

Para quem está curioso, neste momento estou planejando manter as filiais organizadas assim:

• master será o que está disponível para qualquer pessoa que queira construir um WordPress Widget,
• desenvolver é estritamente para desenvolvedores incluem aqueles que sabem usar o Composer e os tópicos discutidos neste post,
• release é o que será usado para fornecer uma demonstração de trabalho.

Por enquanto, porém, revise o que é abordado nesta postagem e retomaremos isso na próxima postagem.