Composerización de proyectos en Drupal 8

Enviado por Juan el Jue, 15/02/2018 - 11:25
Alondra de la parra. Photo by Deutsche Welle.

No pretendo revolucionar el lenguaje y exigirle a la RAE que admita el verbo Composerizar en su diccionario, pero quiero dejar constancia de mi experiencia al integrar Composer a antiguos proyectos de Drupal que no lo utilizaban y el por qué moverse a este esquema, de forma que algunos programadores que estuvieran acostumbrados a trabajar diferente con pasadas versiones (hablo tanto de Drupal 7 como versiones más tempranas de 8) puedan encontrar aquí una referencia que los guíe más fácilmente a encontrar el camino hacia la verdad y la felicidad. (!)

—"¿Pero para qué Composer?"—, preguntó el dinosaurio

Puede parecer una pregunta con una respuesta muy obvia para quienes se integraron a Drupal recientemente o quienes trabajan con frameworks como Laravel, pero hablemos un poco de la vieja escuela: de cuando para crear un nuevo sitio en Drupal 6 o 7 nos bastaba con descargar el archivo tarball de Drupal.org, crear una base de datos e instalar el sitio; para instalar un módulo subíamos el archivo por FTP a la carpeta sites/all/modules, lo activábamos desde la interfaz de administración y listo. Luego vino Drush y descubrimos que podíamos hacer más rápido estas tareas desde la consola de comandos: actualizar los módulos, vaciar las cachés, hacer respaldos, etc.

Después vino Drupal 8 con su core basado en Symfony, que más que un simple CMS adquirió capacidades para comportarse como un framework completo y las reglas del juego empezaron a cambiar; aun así podíamos construir y mantener nuestros sitios sin dificultad, en el más horrible de los casos podíamos actualizar Drupal eliminando antes las carpetas core y vendor como nos prescribía el archivo README y estábamos hechos.

Aquí empezaron a brotar los primeros síntomas de molestia que indicaban que tal vez tendríamos que hacer las cosas de manera diferente porque actualizar un sitio a mano se tornaba muy complejo y tardado (ya que el core es mucho más pesado en comparación a las versiones anteriores). Bueno, Drush podría evitarnos algunos dolores de cabeza por un tiempo más hasta que apareció Drush 9, ahora despreciando sus viejas habilidades para descargar módulos y actualizar sitios; el niño dice que todo eso no es tema suyo y Composer debería estar haciendo los deberes, y ahora sí, como diría esa poetiza cubana llamada Niurka: topaste con el muro de Berlín.

Esto tiene una razón de ser, así que sacudámonos un poco la renuencia al cambio y entendamos de una vez por todas lo que está pasando. Los sistemas se vuelven más complejos: aparecen nuevas versiones de PHP, algunas librerías se actualizan y otras no, unas dependen de otras y la posibilidad de que tu sitio no funcione a razón de que no tenías la versión correcta de alguno de esos componentes crece rápidamente. Otra situación es que los flujos de trabajo cambian: se vuelven indispensables los repositorios Git colaborativos y la administración de diferentes entornos de desarrollo, y así las tareas de mantenimiento se tornan más complejas. Aquí es donde Composer entra al rescate y nos ayuda a resolver gran parte de este panorama lleno de caos y destrucción.

El mundo de Composer no es hermoso y maravilloso, pero definitivamente sigue siendo mejor que lidiar con la enredadera de dependencias por cuenta propia. Imagina un escenario en el que tienes instalado el módulo A que depende de la versión 1.0 de la librería X, pero ahora necesitas instalar el módulo B que requiere la versión 1.5 de X que es incompatible con su predecesora. Composer es justamente eso: un gestor de dependencias que descarga las versiones indicadas para nuestro proyecto (y las dependencias de sus dependencias y así sucesivamente). La instalación de Composer es muy sencilla y los pasos a seguir se pueden encontrar en su sitio web.

El Composer Drupal project y la gestión de módulos

Composer tiene la habilidad también de crear nuevos proyectos basados en frameworks como Symfony, Laravel o Drupal. Para esto nos interesa el Drupal project, para lo cual podemos ejecutar el siguiente comando:

composer create-project drupal-composer/drupal-project:8.x-dev my_site_name_dir --stability dev --no-interaction

Y con eso tenemos el código boilerplate para comenzar un proyecto desde cero. Este proyecto recién creado tendrá un archivo composer.json con la configuración lista para que el sitio sea manejado con Composer.

Además del repositorio predeterminado donde Composer descarga las dependencias que necesita para el proyecto, este composer.json tendrá la dirección de un repositorio adicional donde los módulos y temas de Drupal son vistos como dependencias, de manera que para instalar el módulo Pathauto, por ejemplo, es tan simple como teclear el siguiente comando desde el directorio base de nuestro sitio:

composer require drupal/pathauto

Así Composer se encarga de descargar la versión más adecuada para nuestro sitio, similar a lo que hacíamos antes con drush dl. La actualización de core y módulos también se realiza con el afamado composer update. También es posible indicarle a Composer que ciertos módulos sólo estén disponibles en nuestro entorno de desarrollo y no en producción.

Otro aspecto a considerar: la exclusión de core y vendor

Cuando hablamos de trabajar en equipo con varios desarrolladores se vuelve indispensable el uso de Git como repositorio para trabajar en conjunto. Si miramos el archivo example.gitignore que se incluye en la base de Drupal, nos sugiere una configuración que excluye las carpetas core y vendor donde se almacenan el núcleo y las librerías que le dan vida a nuestro sitio. Esto atiende el punto mencionado anteriormente en el que explicaba las complicaciones que pueden venir con el versionado de las dependencias.

Aunado a esto, si incluímos esas carpetas nuestros repositorios se volverán mucho más pesados y difíciles de mantener. En mi proceso de experimentación llegué a tener dificultades con algunas librerías de la carpeta vendor que no podían ser agregadas correctamente al repositorio de mi proyecto. Esto se explica porque dentro de sí mismas almacenaban otros subrepositorios, los cuales llevan un control de cambios ajeno al repositorio principal; forzar la carga de estos archivos al repositorio de nuestro Drupal será garantía de conflictos cuando tengamos que actualizar esas dependencias. ¿Te parece divertido? Mejor nos quitamos de problemas y le delegamos también la gestión de estas carpetas a Composer.

Ahora sí, la composerización

Todo se lee muy bonito hasta aquí, ¿pero qué hay de nuestros sitios Drupal 8 existentes que no fueron creados con el Composer Drupal project y no tienen la estructura ni el composer.json adecuado para ser gestionados por este administrador de dependencias? Seguramente estos proyectos ya vendrán con un composer.json incluido pero básicamente carecerá de dos elementos importantes para administrar los módulos de Drupal como dependencias:

  • Agregar el repositorio de proyectos de Drupal.
  • Configurar las rutas donde Composer debe colocar los módulos y temas de Drupal.

Para esto nos podemos apoyar de un sencillo plugin de Composer llamado composerize-drupal que puede ser instalado con el siguiente comando: 

composer global require grasmash/composerize-drupal

La recomendación aquí es, claramente, primero ejecutar este plugin en un entorno de desarrollo con su debido previo respaldo: estás advertido.

Debes ejecutarlo en una instancia de tu sitio que esté actualmente operativo; si tu sitio de Drupal lo has descargado desde un repositorio que ya excluía las carpetas core y vendor pensando que Composer las descargará una vez "composerizado", no funcionará. Por el contrario, una vez ejecutado el plugin con éxito podrás excluir en el archivo .gitignore esas dos carpetas y proceder a la carga de tu repositorio.

Visto desde la carpeta raíz del sitio, el comando para convertir tu Drupal a un proyecto de Composer es el siguiente:

composer composerize-drupal --composer-root=. --drupal-root=.

Así de sencillo, aunque recomiendo revisar la documentación completa del uso de este plugin que se encuentra en el repositorio Github del proyecto.

Otro enlace que recomiendo ampliamente para terminar de entender los pormenores del uso de Composer en Drupal es el siguiente: Drupal 8 Composer Best Practices, un artículo buenísimo al que, justamente, llegué a través del mismísimo composerize-drupal.