Desenvolvimento local com o zinnector dev

zinnector dev executa um WordPress real em sua própria máquina, servindo os plugins e temas em seu projeto, com uma versão do PHP à sua escolha. Este artigo explica os dois ambientes de execução que ele pode usar, como selecionar versões, o que é servido de onde e onde o ambiente de execução fica no disco — para que o que você testa localmente seja o que você implanta.

Os dois ambientes de execução, e por que ambos são reais

O Playground é o padrão. O WordPress Playground compila o PHP para WebAssembly e o executa dentro do Node, de modo que um notebook sem nada instalado além do Node inicializa um WordPress em segundos. Qualquer PHP de 5.2 a 8.5 está disponível. Ele possui um pequeno conjunto de extensões PHP (intl, redis, memcached conforme medido na compilação atual), o que é suficiente para a maioria dos trabalhos com plugins e temas.

O Docker executa contêineres nativos php-fpm e MariaDB. É mais lento, precisa de um daemon do Docker e de cerca de 1,2 GB de imagens, e oferece suporte ao PHP 7.4 a 8.5 — mas executa um PHP nativo com o conjunto completo de extensões, incluindo imagick e gd. É a resposta honesta quando o que você precisa testar é uma extensão que a compilação do WebAssembly não possui.

zinnector dev                       # playground
zinnector dev --runtime docker      # PHP nativo + MariaDB

O Docker nunca é acionado como fallback de forma silenciosa. Um desenvolvedor que acha que está no WebAssembly e na verdade está no Docker recebeu a resposta errada de uma ferramenta que tenta ajudar, por isso ele deve ser solicitado pelo nome.

Escolhendo versões do PHP e do WordPress

zinnector dev --php 8.1 --wp 6.7    # desenvolver em um par específico
zinnector dev --port 9401           # quando a 9400 estiver ocupada
zinnector dev --no-login            # não iniciar sessão no wp-admin automaticamente
zinnector dev --verbose             # mostrar a própria saída do ambiente de execução

Os padrões vêm de zinnector.json no projeto — php, wordpress, runtime e port — que zinnector new grava e que você deve confirmar com commit, para que todos no projeto executem as mesmas versões. Uma flag na linha de comando tem preferência sobre o arquivo para essa execução.

A versão que você declara e a versão que é executada são fatos diferentes. zinnector dev --once inicializa o ambiente de execução, imprime o que ele realmente relata — versão do PHP, versão do WordPress, extensões carregadas — e para. zinnector check --probe usa a mesma medição ao comparar seu projeto com um slot de hospedagem.

O que é servido a partir do seu projeto

O ambiente de execução monta os diretórios wp-content/plugins, wp-content/themes e wp-content/mu-plugins do seu projeto diretamente, de modo que um arquivo salvo fica ativo na próxima recarga. Os diretórios que existem mas não contêm conteúdo real deliberadamente não são montados: um themes/ vazio montado sobre os próprios temas do ambiente de execução deixaria o WordPress sem nenhum tema, o que resulta em um erro 500 em branco em vez do seu site. É por isso que o scaffolding mantém diretórios vazios com um .gitkeep e por que eles não ocultam nada até que você coloque um tema neles.

Onde o ambiente de execução fica

O ambiente de execução do WordPress é baixado no primeiro uso em vez de vir empacotado com a CLI — o pacote que carrega cada compilação do PHP tem cerca de 570 MB, e um desenvolvedor que apenas lista sites não deve pagar por isso. Ele é mantido no cache próprio do Zinnector®, em ~/.cache/zinnector/runtimes/playground/<version> (ou onde ZINNECTOR_CACHE_DIR apontar), nunca no seu projeto, para que não possa parar no seu repositório ou na árvore que zinnector push mede. O download é feito pelo seu próprio npm, executado como node npm-cli.js — nunca por meio de um shell.

A versão do ambiente de execução é fixada na versão da CLI, para que dois desenvolvedores em um mesmo projeto executem as mesmas compilações de PHP. zinnector dev --reset-runtime descarta o ambiente de execução instalado e o instala novamente, o que é a correção para um ambiente de execução que foi instalado mas não inicializa.

No Node 26 ou mais recente

A CLI em si é executada em qualquer Node a partir da versão 24. O módulo nativo do ambiente de execução, no entanto, fornece binários pré-compilados apenas para o Node 24 e 25 (a partir de setembro de 2026). Em vez de compilar qualquer coisa — o que no Windows significa instalar o Visual Studio — o Zinnector® busca um Node 24 apenas para o ambiente de execução, com cerca de 30 MB, verificado em relação às somas de verificação publicadas em nodejs.org, no mesmo cache. O prompt de instalação informa isso quando é aplicado. Nada sobre o seu próprio Node é alterado.

Relacionado

• Primeiros passos · Implantação · Referência de comandos · Solução de problemas