Turborepo en proyectos PHP: cuándo tiene sentido (y cuándo no)

“¿Deberías usar un monorepo?” La respuesta honesta es la misma que para casi todo en software: depende.

Depende del tamaño de tu equipo. Depende de cuántos proyectos tienes. Depende de si compartes código entre ellos. Depende de tu pipeline de CI/CD. Depende, depende, depende.

Así que en lugar de darte una respuesta universal, te voy a dar los contextos donde tiene sentido y donde no.

Qué es un monorepo (en 30 segundos)

Un monorepo es un solo repositorio Git que contiene múltiples proyectos o paquetes. En lugar de tener api, frontend, admin-panel en tres repos separados, los tienes todos en uno.

Turborepo es una herramienta de Vercel que optimiza builds y tasks en monorepos JavaScript/TypeScript. Cachea resultados, paraleliza tareas y solo re-ejecuta lo que cambió.

El detalle: Turborepo es para el ecosistema JS/TS. ¿Y PHP?

PHP en un monorepo: las opciones

PHP no tiene el mismo ecosistema de herramientas para monorepos que JS, pero eso no significa que no se pueda hacer. Hay dos enfoques comunes:

1. Monorepo mixto (el más común en proyectos modernos)

mi-proyecto/
  apps/
    api/          # Laravel (PHP)
    web/          # Next.js o Astro
    admin/        # Vue o React
  packages/
    ui/           # Componentes compartidos
    types/        # TypeScript types
  turbo.json
  package.json

Turborepo maneja el frontend, Laravel vive en su rincón. Funciona bien porque cada parte hace lo suyo.

2. Monorepo PHP puro (más raro, más opinionated)

Usando Composer workspaces (sí, existen aunque no son tan conocidos):

mi-proyecto/
  packages/
    domain/       # Lógica de negocio pura
    infrastructure/ # Eloquent, queries, etc.
    api/          # Laravel app
  composer.json   # workspace root

Esto es más common en arquitecturas hexagonales o DDD donde quieres separación real entre capas.

Cuándo SÍ tiene sentido

Tienes un frontend JS + backend Laravel

Este es el sweet spot. Si tienes un API en Laravel y un frontend en React/Vue/Astro, un monorepo te da:

• Un solo git clone para todo el equipo
• Cambios atómicos que tocan frontend y backend al mismo tiempo
• CI/CD que sabe exactamente qué cambió y solo buildea lo necesario

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"]
    }
  }
}

Turborepo se encarga del JS, tu pipeline de PHP (PHPUnit, Pint, etc.) corre aparte pero en el mismo repo.

Tienes múltiples apps que comparten código

Si tienes app-cliente y app-admin que comparten componentes UI, tipos TypeScript o incluso helpers PHP — un monorepo elimina la pesadilla de sincronizar versiones entre repos.

Sin monorepo: cambias un componente → publicas paquete → actualizas dependencia en dos repos → rezas para que todo funcione.

Con monorepo: cambias el componente, todo actualiza automáticamente. Punto.

Equipo pequeño, muchos proyectos

Con 2-4 personas manejando 4+ proyectos, tener todo en un lugar reduce el context switching. Un solo lugar para issues, PRs, y CI/CD.

Cuándo NO tiene sentido

Proyecto solo de Laravel sin frontend separado

Si tienes una app Blade + Livewire donde el frontend vive dentro del mismo proyecto Laravel, no hay nada que monorepoar. Estás sumando complejidad sin ningún beneficio.

Equipos grandes con dominios separados

Si tienes 20 developers y cada equipo owna su propio servicio, un monorepo puede convertirse en un cuello de botella. Los builds tardan más, los conflictos de merge aumentan, y la autonomía de equipo se complica.

A ese nivel necesitas algo más serio: Nx con módulos, o simplemente aceptar que los repos separados + buena automatización de releases funciona bien.

Cuando nadie del equipo lo conoce

Un monorepo mal configurado es peor que repos separados. Si vas a adoptar esta arquitectura, alguien del equipo tiene que entender cómo funciona Turborepo, Composer workspaces, y el pipeline de CI/CD resultante.

La deuda técnica de “lo instalamos pero nadie sabe cómo funciona” es real y dolorosa.

El setup mínimo que funciona

Si después de todo esto decides que sí aplica en tu contexto, aquí el mínimo para empezar:

npx create-turbo@latest mi-proyecto
cd mi-proyecto
mkdir apps/api
cd apps/api
composer create-project laravel/laravel .

En turbo.json, agrega tasks solo para los paquetes JS. Para Laravel, configura tu pipeline de CI aparte (GitHub Actions, por ejemplo) apuntando a apps/api/.

El truco es no intentar que Turborepo “maneje” PHP. Déjalo hacer lo suyo con JS y maneja PHP con las herramientas de PHP.

Conclusión

Los monorepos son una herramienta, no una solución universal. En proyectos Laravel + frontend JS con equipos medianos, pueden simplificar mucho la vida. En proyectos simples o con equipos grandes y bien separados, pueden complicarla.

La próxima vez que alguien te pregunte “¿debería usar un monorepo?”, ya sabes la respuesta correcta: depende.

¿Estás usando monorepos con PHP en tu empresa? Me interesa saber cómo lo estructuraron — puedes escribirme en X/Twitter o contactarme directo.