VHS Development para TYPO3

Por qué la versión de desarrollo de VHS es un arma de doble filo para agencias TYPO3

VHS (ViewHelpers Supplementary) es, con más de 300 ViewHelpers, la ampliación Fluid más completa para TYPO3. La versión de desarrollo ofrece nuevos ViewHelpers y correcciones de errores antes de que se integren en un release estable. Para desarrolladores que trabajan en proyectos actuales y esperan un bugfix específico o una nueva funcionalidad, eso es una ventaja. Para webs en producción es un riesgo: las versiones de desarrollo no están completamente testadas y pueden cambiar de forma incompatible entre commits.

La decisión de usar VHS Development no es técnica, sino organizativa: tiene el equipo capacidad para testear y reaccionar rápidamente si algo se rompe. Y existe la disciplina organizativa para sustituir la versión de desarrollo por un release estable antes del go-live.

Escenarios de uso habituales

Acceso a bugfixes antes del siguiente release estable. Un proyecto usa el ViewHelper VHS v:format.trim que tiene un bug en la versión estable. El fix ya existe en la rama de desarrollo, pero el siguiente release estable está previsto en 4 semanas. El equipo cambia temporalmente a VHS Development para aprovechar el bugfix inmediatamente.

Evaluación de nuevos ViewHelpers para un relanzamiento. Un relanzamiento TYPO3 comienza en 3 meses. El equipo de desarrollo evalúa si nuevos ViewHelpers VHS pueden simplificar el código de las plantillas. La versión de desarrollo se instala en un entorno local de desarrollo, se prueba y los resultados alimentan la decisión arquitectónica.

Contribución al desarrollo de VHS. Agencias que contribuyen con ViewHelpers propios o reportan bugs trabajan con la versión de desarrollo para testear sus parches contra el estado actual del código.

Arquitectura técnica

VHS Development no es una extensión separada, sino el estado de desarrollo actual del repositorio VHS en GitHub (FluidTYPO3/vhs). La instalación se realiza vía Composer con dev-main o una rama específica. La configuración minimum-stability en composer.json debe ajustarse a dev, lo cual afecta a todos los paquetes.

Los más de 300 ViewHelpers cubren áreas como: Content (renderizado de elementos, acceso FAL, manejo de medios), Format (manipulación de strings, fechas, números, JSON, Markdown), Iterator (operaciones con arrays, ordenación, filtrado, paginación), Page (navegación del árbol de páginas, breadcrumb, sitemap), Media (manipulación de imágenes, embedding de vídeo) y Security (verificaciones de acceso, estado de login).

La versión de desarrollo puede contener ViewHelpers cuya API aún cambia. Entre dos releases estables, la signatura de 5 a 15 ViewHelpers cambia típicamente en la rama de desarrollo.

Problemas frecuentes y soluciones

Un composer update rompe plantillas existentes. Un composer update obtiene la versión de desarrollo más reciente donde se ha renombrado un parámetro de ViewHelper. Todas las plantillas que usan ese parámetro arrojan errores. Solución: hacer commit consistente del Composer lock file e instalar VHS Development con una referencia de commit fija: composer require fluidtypo3/vhs:dev-main#abc1234.

minimum-stability dev afecta a otros paquetes. Si minimum-stability se establece en dev, otros paquetes también pueden instalar versiones inestables. Solución: mantener "minimum-stability": "stable" y definir VHS Development explícitamente como excepción: "fluidtypo3/vhs": "dev-main as 6.99.0".

La pipeline CI/CD falla con la versión de desarrollo. Tests automáticos y despliegues pueden fallar si GitHub no está temporalmente accesible o la rama recibió un force push. Solución: para pipelines CI/CD usar un mirror Composer local (Satis) o cambiar al release estable.

Migración y compatibilidad de versiones

Los releases estables de VHS siguen los ciclos LTS de TYPO3: VHS 6.x soporta TYPO3 v11, VHS 7.x soporta TYPO3 v12. La rama de desarrollo apunta a la siguiente versión major.

Gosign recomienda la siguiente estrategia: en entornos de desarrollo y ramas feature usar la versión de desarrollo para evaluar nuevos ViewHelpers. En staging y producción usar exclusivamente releases estables. Si un bugfix crítico solo está disponible en development, fijar el commit específico como referencia Composer y dejar un comentario TODO en el código que aparezca en la siguiente revisión de release estable.