Mejor código de WordPress: el archivo de bloqueo del compositor
Antes de concluir nuestra discusión sobre Composer, nos queda una cosa importante por discutir: el directorio de proveedores (y por extensión, el archivo de bloqueo de Composer).
Específicamente, necesitamos hablar sobre por qué no necesitamos enviar el directorio de proveedores al repositorio, sino cómo nuestros colaboradores pueden estar seguros de que tienen la última versión del software necesario para trabajar con nuestra base de código.
Usar herramientas de calidad de código para escribir mejor código de WordPress es importante, sí, pero también es importante comprender cómo administrar adecuadamente las dependencias y nuestro repositorio. Entonces, antes de ver dichas utilidades, revisemos el archivo de bloqueo, el papel que desempeña y por qué no necesitamos enviar el directorio de proveedores a nuestro repositorio.
Mejor código de WordPress con el archivo de bloqueo Composer
Para aquellos que trabajan con WordPress, y quizás en otros marcos y bases basados en PHP (realmente no lo sé, ya que tiendo a no trabajar con ellos), existe una confianza en Composer, lo cual es algo bueno.
Esto también puede llevar a querer comprometer todo el control de fuente del directorio de proveedores, lo cual no es bueno.
Como se mencionó en la publicación anterior :
Y no recomiendo consultar el directorio de proveedores en su repositorio. Eso puede convertirse en un directorio enorme más tarde y puede socavar el propósito completo de Composer.
Entonces, ¿cómo podemos asegurarnos de que no estamos enviando archivos innecesariamente (y, por lo tanto, inflando el tamaño de nuestro repositorio) al repositorio mientras nos aseguramos de que nuestros colaboradores estén usando la misma versión del software que nosotros?
El deseo de comprometer el directorio de proveedores
Para aquellos de ustedes que han ejecutado Composer y están familiarizados con al menos ver el directorio de proveedores, es probable que estén acostumbrados a ver múltiples directorios de dependencias que están instaladas.
Y son útiles; de lo contrario, no los habrías incluido, ¿verdad?
Pero esto es lo que pasa con el directorio de proveedores : incluso si solo tiene algunas dependencias instaladas con su proyecto, el tamaño del archivo en sí puede ser grande. Y esto puede ser aún mayor cuando tiene muchas dependencias.
De todos modos, enviar esto al control de fuente parece tener sentido, ¿verdad? Queremos asegurarnos de que todos tengan la misma versión del software que estamos usando y queremos asegurarnos de que no tengan que lidiar con Composer.
Sin embargo, hay otra manera. Y mantiene nuestro repositorio pequeño al mismo tiempo que se asegura de que las versiones de nuestras dependencias se mantengan sincronizadas con aquellos que clonan el repositorio, se comprometen con el repositorio o para cualquier utilidad de integración continua que use el repositorio.
Comprender el archivo de bloqueo
Antes de hablar sobre el directorio de proveedores, quiero referirme a otro aspecto importante de Composer: el archivo de bloqueo. Es decir, si ejecuta el comando de instalación o actualización en su terminal, verá un archivo de bloqueo generado junto con el directorio del proveedor.
¿Qué es este archivo?
La publicación anterior mostró un archivo de configuración de ejemplo. Una de las cosas que este archivo también nos permite hacer es definir bibliotecas de terceros, o dependencias, que podemos usar en nuestros proyectos.
He hablado de esto en otras publicaciones (y podemos ver esto un poco más adelante en esta serie). Pero aquí es donde entra en juego el archivo de bloqueo.
En resumen, el archivo de bloqueo siempre contiene información sobre la versión, la versión exacta, de las dependencias que se están utilizando con el proyecto la última vez que se ejecutó la instalación o actualización.
Cuando Composer ha terminado de instalarse, escribe todos los paquetes y las versiones exactas de los mismos que descargó en el archivo composer.lock, bloqueando el proyecto en esas versiones específicas.
Debe confirmar el archivo composer.lock en el repositorio de su proyecto para que todas las personas que trabajan en el proyecto estén bloqueadas en las mismas versiones de dependencias (más información a continuación).
El objetivo es asegurarse de que todos ejecuten la misma versión de las dependencias del proyecto, no versiones anteriores, ni versiones más nuevas, sino la misma versión.
Entonces, cuando ejecuta la instalación de composer cuando se incluye un archivo de bloqueo en el repositorio, usará la versión del software tal como se define en el archivo de bloqueo.
Y esto garantiza que todos estén ejecutando la misma versión de cada dependencia y, por lo tanto, puede evitar la necesidad de enviar el directorio de proveedores al control de código fuente.
Escribir código de mayor calidad
Entonces, ¿dónde vamos desde aquí?
Ahora que entendemos cómo usar Composer y cómo usar el archivo de bloqueo, podemos comenzar a hablar sobre las dependencias reales que ayudan a mejorar la calidad de nuestro código.
Y cuando hablamos de escribir código de mayor calidad, existen utilidades hechas exactamente para eso. Así que en las próximas publicaciones, vamos a ver algunos de ellos.