Instalando paquetes desde GitHub con Composer

Integrar un paquete propio en Laravel puede ser rápido y confiable si sigues un flujo claro: configurar Composer con un repositorio de GitHub, instalar el paquete, y ajustar el proyecto guiado por tests automatizados. Aquí verás cómo limpiar la app, declarar repositories en composer.json, publicar un release, y usar TDD para resolver conflictos sin revisar endpoint por endpoint.

¿Cómo preparar la aplicación para usar un paquete desde GitHub?

Antes de instalar, es clave limpiar el código que ya migraste al paquete para evitar duplicidades y referencias rotas.

¿Qué archivos limpiar antes de instalar?

• Borrar el modelo Rating que fue movido al paquete.
• Borrar la carpeta utils con los traits usados para ratings.
• Borrar los eventos migrados relacionados con rating.
• Borrar las migraciones que interfieran con la tabla de ratings.
• Considerar el archivo de configuración rating.php: inicialmente se borra para publicarlo luego; más adelante se decidió mantenerlo para no repetir trabajo.

¿Qué referencias de código actualizar después?

• Reemplazar referencias como App\Rating por la clase del paquete. Importar con el namespace correcto.
• En User, importar los traits CanRate y CanBeRated del paquete.
• En Product, importar el trait correspondiente e implementar la interfaz Ratable.
• Implementar el método name que retorna la propiedad name del modelo.
• En Usuario, implementar las interfaces Ratable y Qualifier. Agregar el método name que devuelva el nombre o el email.

¿Cómo verificar el impacto con tests?

• Ejecutar los tests existentes para detectar errores de referencia.
• Usar el stack trace y un response dump para inspeccionar fallos; por ejemplo, mensajes del tipo “la clase App\Rating no existe”.

¿Cómo configurar composer.json y publicar un release?

La instalación desde GitHub requiere declarar un repositories en composer.json y contar con un release público que permita descargar una versión del paquete.

¿Dónde declarar repositories en composer.json?

• Abrir composer.json y agregar la clave repositories como arreglo.
• Incluir un objeto con el tipo de repositorio y la URL del repositorio de GitHub.
• La referencia del paquete debe coincidir con el valor de name declarado en composer.json del paquete.

¿Por qué crear un release en GitHub?

• Permite a Composer descargar una versión concreta del paquete.
• Se creó un release nuevo (por ejemplo, 2.2.3) para publicar la actualización.

¿Cómo instalar el paquete con Composer require?

• Ejecutar composer require usando el nombre del paquete indicado en el campo name del paquete en GitHub.
• Se instalará la última versión disponible. En el ejemplo, se obtuvo una versión superior a 2.2, consistente con las reglas de dependencias explicadas previamente.

¿Cómo usar TDD para alinear el proyecto con el paquete?

Tras la instalación, los tests ayudan a detectar y corregir todas las referencias antiguas, asegurando que las clases del paquete sustituyan a las locales sin romper el sistema.

¿Qué errores esperar tras la instalación?

• Referencias rotas a clases antiguas (ej.: App\Rating no existe).
• Falta de imports adecuados en controladores, recursos y configuración.
• Fallos de validación: por ejemplo, “el valor debe estar entre uno y cinco”.

¿Cómo corregir imports y namespaces?

• Actualizar el archivo de configuración para apuntar a las clases del paquete.
• En RatingResource y ProductController, importar la clase correcta con su namespace.
• En los tests unitarios, borrar referencias a clases locales e importar eventos y modelos del paquete.
• Repetir la ejecución de tests para validar cada corrección.

¿Cómo manejar validaciones y localización?

• Si los mensajes aparecen en inglés, ajustar el idioma de la app a español en APP para que el paquete responda en español.
• Corregir detalles de formato, como mayúsculas/minúsculas en los mensajes esperados.
• Importar la librería adecuada si cambió la referencia usada antes.
• Ejecutar nuevamente los tests hasta que todos pasen. Resultado: toda la suite en verde y el paquete integrado.

Con este flujo, Composer permite definir repositorios alternativos (como GitHub), instalar el paquete por versión (vía release) y apoyarte en TDD para resolver conflictos de forma rápida, sin probar manualmente cada endpoint.

¿Quieres que revisemos tu composer.json o el mapeo de namespaces para detectar el próximo punto de mejora?