Cuando desarrollas un paquete en Laravel, el paso más importante es demostrar que funciona dentro de una aplicación real. Aquí se aborda cómo limpiar tu proyecto, configurar un repositorio de GitHub como fuente de paquetes en Composer y resolver todos los conflictos que surgen al reemplazar código local por un paquete externo, apoyándote en tests automatizados para validar cada cambio.
¿Cómo preparar tu aplicación antes de instalar el paquete?
Antes de indicarle a Composer que descargue el paquete, es necesario eliminar todos los archivos que ya fueron migrados al paquete [00:22]. Esto incluye:
- El modelo Rating que existía en la carpeta
app.
- La carpeta
utils con los traits.
- Los eventos que se migraron al paquete.
- Las migraciones relacionadas con la tabla de ratings.
- El archivo de configuración
rating.php, que se publicará posteriormente desde el paquete.
Esta limpieza evita conflictos de clases duplicadas y garantiza que la aplicación dependa exclusivamente del paquete.
¿Cómo configurar un repositorio de GitHub en Composer?
Composer utiliza repositorios como fuentes para descargar paquetes. Por defecto trabaja con Packagist, pero puedes definir repositorios alternativos directamente en tu composer.json [01:02]. Para ello, se declara una key llamada repositories, que es un arreglo de objetos donde especificas el tipo y la URL:
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/tu-usuario/tu-repositorio"
}
]
}
Un detalle fundamental: debes crear un release en tu repositorio de GitHub para que Composer pueda descargar una versión específica del paquete [01:28]. Una vez publicado el release, ejecutas en la terminal:
bash
composer require sojeda/rate
El nombre del paquete corresponde al valor declarado en la propiedad name del composer.json del paquete, y debe coincidir con el nombre del repositorio [01:48]. Composer instalará la última versión disponible; en este ejemplo, una versión superior a 2.2, siguiendo las reglas de versionado semántico que se manejan con el operador ^.
¿Cómo resolver conflictos usando TDD después de integrar el paquete?
Al ejecutar los tests después de la instalación, aparecerán múltiples errores porque el proyecto aún contiene referencias a clases locales que ya no existen [02:30]. La estrategia consiste en correr los tests e ir resolviendo cada fallo de forma incremental.
¿Qué referencias se deben actualizar?
Todas las importaciones que apuntaban a App\Rating deben cambiarse al namespace del paquete [03:25]. Esto aplica a:
- El archivo de configuración.
- Los Resource como
RatingResource.
- Los controladores, por ejemplo
ProductController.
- Los tests unitarios, donde también se reemplazan las referencias de eventos y modelos.
Además, los modelos User y Product deben importar los traits del paquete: CanRate y CanBeRated [02:55]. Al implementar interfaces como Ratable y Qualifier, cada modelo debe definir el método name() que retorna la propiedad correspondiente, como $this->name o $this->email [03:15].
¿Cómo afecta la internacionalización a los tests?
El paquete incluye soporte de idiomas (localization), lo que significa que los mensajes de validación se devuelven en el idioma configurado en la aplicación [04:12]. Si los tests esperan mensajes en español pero la aplicación está en inglés, fallarán. La solución es cambiar el idioma en el archivo de configuración app.php a español y asegurar que las aserciones coincidan con el formato exacto, incluyendo mayúsculas y minúsculas.
Después de ajustar las referencias, los namespaces, el idioma y las interfaces, todos los tests pasan correctamente [04:40]. Esto demuestra una de las grandes ventajas de TDD: poder validar la integración completa sin probar manualmente cada endpoint.
Composer permite definir distintos tipos de repositorio, y utilizar GitHub como fuente temporal es una práctica muy útil durante el desarrollo. ¿Ya has creado tu propio paquete? Comparte tu experiencia en los comentarios.
