CodeForge

TypeScript de Cero a Experto / Configuración pro

Project references: TypeScript a escala

Teoría18 min20 XP

Un proyecto crece, y a veces se parte en varios: una app, una librería compartida, un paquete de utilidades —todos en un mismo repositorio (un monorepo)—. Los project references de TypeScript orquestan esos proyectos: compilan solo lo que cambió, imponen límites claros entre ellos, y aceleran todo. Es la configuración a escala, la que usan los equipos grandes.

El edificio dividido en alas independientes

El problema: compilar todo, siempre

En un monorepo con varios paquetes, sin project references, tsc trata todo como una masa: cualquier cambio recompila el mundo entero, y no hay límites claros de quién puede importar de quién. Los project references dividen eso en unidades con dependencias declaradas:

estructura del monorepo
// un monorepo típico:
//   packages/
//     ui/          (librería de componentes)
//     utils/       (utilidades compartidas)
//     app/         (la aplicación, usa ui y utils)

// cada paquete tiene su tsconfig con "composite": true, y el de la app
// DECLARA de quién depende con "references":
packages/app/tsconfig.json
{
"compilerOptions": {
  "composite": true       // habilita que este proyecto sea referenciable
},
"references": [
  { "path": "../ui" },    // la app depende de ui
  { "path": "../utils" }  // y de utils
]
}

composite: true marca un proyecto como una unidad "referenciable" (TS genera información extra para compilarlo por separado). references declara sus dependencias. Con eso, tsc --build compila los proyectos en el ORDEN correcto (primero ui y utils, luego app) y, en las siguientes veces, solo recompila lo que cambió.

Qué te dan

¿Los necesitas?

¿Cuál es la señal de que un proyecto SÍ se beneficiaría de project references?

Mini-reto

De reconocimiento, no de código: 1) busca un proyecto open source que sea un monorepo (muchos tienen una carpeta packages/) y mira si sus tsconfig.json usan composite y references; 2) dibuja en un papel el grafo de dependencias de tres paquetes ficticios (app → ui → utils) y escribe qué references tendría cada uno; 3) reflexiona: ¿tu proyecto actual los necesita? (casi seguro que no, y eso está bien). Reconocer la herramienta es el objetivo.

Qué sigue

Tu configuración de TypeScript está completa. Falta el compañero que trabaja a su lado: ESLint. La próxima lección conecta ESLint con TypeScript para un linting que ENTIENDE los tipos —cazando problemas que ni el compilador ni un linter normal ven por separado. La última pieza del entorno profesional.