En el desarrollo moderno de aplicaciones PHP con CodeIgniter 4, uno de los mayores retos es mantener un flujo de trabajo eficiente entre desarrollo local, control de versiones y gestión de dependencias.

Este artículo explica una arquitectura híbrida usando Composer + Git + symlinks que permite trabajar módulos de forma profesional sin depender del directorio vendor.

🧠 El problema clásico

Cuando trabajamos con módulos reutilizables (inventarios, CFDI, pagos, etc.), normalmente terminamos instalando todo en vendor/, lo que genera problemas:

  • No se puede editar código fácilmente
  • Debug complicado
  • Cambios se pierden con composer update
  • Duplicación de código
  • Dificultad para mantener múltiples proyectos

💡 La solución: arquitectura híbrida

La solución moderna combina tres herramientas:

  • Composer como gestor de dependencias
  • Git como control de versiones
  • Symlinks para desarrollo en vivo

Estructura típica:

~/fuentes/
   ci4-project/
   boilerplateInventory/
   boilerplateProducts/

⚙️ Configuración en Composer

En el composer.json del proyecto principal:

"repositories": [
  {
    "type": "path",
    "url": "../boilerplateInventory",
    "options": {
      "symlink": true
    }
  },
  {
    "type": "vcs",
    "url": "https://github.com/julio101290/boilerplateInventory"
  }
]

📁 Path repository (desarrollo local)

Este tipo de repositorio indica a Composer que use una carpeta local en lugar de descargar el paquete.

Beneficios:

  • Cambios en tiempo real
  • Debug directo
  • No depende de vendor

🌐 VCS repository (GitHub)

Sirve como respaldo cuando el path no existe o en servidores de producción.

🔥 El problema de versiones

Muchos módulos requieren:

^1.0.0

Pero en desarrollo usamos:

dev-main

Esto genera conflictos.

🛠️ Solución: alias de versión

La solución correcta es:

"julio101290/boilerplateinventory": "dev-main as 1.2.6"

Esto le dice a Composer que trate el código local como versión estable.

⚡ Resultado del sistema

  • ✔ Desarrollo en vivo
  • ✔ Debug funcional
  • ✔ Compatibilidad con dependencias
  • ✔ Sin tocar vendor
  • ✔ Respaldo en GitHub

🧪 Flujo de trabajo real

cd ~/fuentes/boilerplateInventory
git add .
git commit -m "cambios"
git push

Los cambios se reflejan automáticamente en el proyecto principal.

⚠️ Buenas prácticas

  • Usar nombres consistentes en minúsculas
  • No trabajar dentro de vendor
  • Versionar módulos con tags
git tag v1.2.6
git push origin v1.2.6

🚀 Conclusión

Esta arquitectura permite construir sistemas modulares profesionales con:

  • Desarrollo rápido
  • Debug en vivo
  • Control de versiones limpio
  • Escalabilidad real

Es una forma moderna de trabajar con Composer sin depender de vendor como entorno de desarrollo.