VHS Development para TYPO3

Por que a versão de desenvolvimento VHS é uma faca de dois gumes para agências TYPO3

VHS (ViewHelpers Supplementary) é com mais de 300 ViewHelpers a extensão Fluid mais abrangente para TYPO3. A versão de desenvolvimento entrega novos ViewHelpers e correções de bugs antes de chegarem a um release estável. Para desenvolvedores que trabalham em projetos atuais e aguardam uma correção específica ou recurso novo, isso é uma vantagem. Para sites produtivos, é um risco: versões de desenvolvimento não são completamente testadas e podem mudar de forma incompatível entre commits.

A decisão de usar VHS Development no projeto não é técnica, mas organizacional: a equipe tem capacidade para testar mudanças na biblioteca em tempo hábil? E existe disciplina organizacional para substituir a versão de desenvolvimento por um release estável antes do go-live?

Cenários típicos de uso

Acesso a correções antes do próximo release estável. Um projeto usa o ViewHelper VHS v:format.trim, que tem um bug na versão estável. A correção já existe no branch de desenvolvimento, mas o próximo release estável está previsto apenas em 4 semanas. A equipe troca temporariamente para VHS Development para usar a correção imediatamente e retorna ao release estável depois.

Avaliação de novos ViewHelpers para projeto de relançamento. Um relançamento TYPO3 começa em 3 meses. A equipe de desenvolvimento avalia se novos ViewHelpers VHS podem simplificar o código de templates. A versão de desenvolvimento é instalada em ambiente de desenvolvimento local, testada e os resultados alimentam a decisão de arquitetura.

Contribuição para o desenvolvimento VHS. Agências que contribuem ViewHelpers próprios ao VHS ou reportam bugs trabalham com a versão de desenvolvimento para testar seus patches contra o estado atual do código. Sem versão de desenvolvimento, contribuição significativa não é possível.

Arquitetura técnica

VHS Development não é uma extensão separada, mas o estado de desenvolvimento atual do repositório VHS no GitHub (FluidTYPO3/vhs). A instalação ocorre via Composer com dev-main ou um branch específico.

VHS em si tem como única dependência rígida o TYPO3 Core (Fluid Template Engine). Os mais de 300 ViewHelpers cobrem áreas como: Content (renderização de elementos, acesso FAL), Format (manipulação de strings, datas, JSON), Iterator (operações com arrays, paginação), Page (navegação, breadcrumb, sitemap), Media (manipulação de imagem, embedding de vídeo) e Security (verificações de acesso, status de login).

A versão de desenvolvimento pode conter ViewHelpers cuja API ainda muda. Parâmetros podem ser renomeados, valores de retorno alterados ou ViewHelpers completamente removidos. Entre dois releases estáveis, tipicamente mudam as assinaturas de 5 a 15 ViewHelpers no branch de desenvolvimento.

Problemas frequentes e soluções

Composer update quebra templates existentes. Um composer update busca a versão de desenvolvimento mais recente, na qual um parâmetro de ViewHelper foi renomeado. Todos os templates que usam esse parâmetro geram erros. Solução: fazer commit consistente do Composer-Lock-File e instalar VHS Development com referência de commit fixa.

minimum-stability dev afeta outros pacotes. Se minimum-stability no composer.json está definido como dev, outros pacotes também podem instalar versões instáveis. Solução: manter "minimum-stability": "stable" e definir VHS Development explicitamente como exceção via alias pattern.

Pipeline CI/CD falha com versão de desenvolvimento. Testes automáticos e deployments baseados em instalações Composer podem falhar com a versão de desenvolvimento se o GitHub estiver temporariamente inacessível. Solução: para pipelines CI/CD, usar um mirror Composer local ou trocar para o release estável.

Migração e compatibilidade de versões

Os releases estáveis VHS acompanham os ciclos LTS do TYPO3: VHS 6.x suporta TYPO3 v11, VHS 7.x suporta TYPO3 v12. O branch de desenvolvimento visa a próxima versão major.

A troca de VHS Development de volta para Stable é geralmente descomplicada, desde que nenhum ViewHelper exclusivo da versão de desenvolvimento esteja sendo usado. A Gosign recomenda: em ambientes de desenvolvimento e feature branches, usar a versão de desenvolvimento para avaliar novos ViewHelpers. Em staging e produção, usar exclusivamente releases estáveis. Se uma correção crítica está disponível apenas no Development, fixar o commit específico como referência Composer e deixar um comentário TODO no código.