Actualizar TypeORM a su versión 0.3 implica ajustes concretos en la forma en que consultamos la base de datos desde nuestros servicios en NestJS. Aunque la arquitectura general de la aplicación se mantiene intacta, los métodos de búsqueda cambiaron su API y es necesario adaptarlos uno por uno. A continuación se detallan los cambios más relevantes y cómo resolverlos de forma ordenada.
¿Qué cambió en los tipos y opciones de búsqueda de TypeORM 0.3?
El primer cambio visible es que el tipo FindConditions dejó de existir [01:20]. En versiones anteriores se utilizaba para construir filtros dinámicos: si llegaban parámetros como limit u offset, se armaba el where progresivamente y se enviaba la consulta. Ahora, ese tipo se reemplaza por FindOptionsWhere, que se importa directamente desde TypeORM. El ajuste es mínimo: basta con sustituir el tipo en la declaración y todo sigue funcionando.
El cambio más significativo está en findOne [01:55]. Antes recibía el ID como primer parámetro de forma directa y las opciones (como relaciones) como segundo parámetro. En la versión 0.3, findOne ya no acepta el ID directamente: todo se envía dentro de un objeto de opciones con la cláusula where.
- Antes:
findOne(id, { relations }) recibía el ID en primer lugar.
- Ahora:
findOne({ where: { id }, relations }) encapsula el filtro dentro de where.
Este patrón se repite en cada servicio donde se utilice findOne, ya sea para buscar un producto, una marca con su brandId, una categoría o cualquier otra entidad [02:40].
¿Cómo se reemplaza findByIds con el operador In?
La función findByIds también quedó marcada como deprecated [03:15]. TypeORM sugiere utilizar findBy junto con el operador In, que se importa directamente desde el paquete. La sintaxis queda así:
typescript
import { In } from 'typeorm';
const products = await this.productRepo.findBy({ id: In(ids) });
El operador In recibe el arreglo de IDs y genera la consulta correspondiente. Este enfoque forma parte de la estrategia de TypeORM 0.3 para ofrecer una API más robusta y compatible con distintos tipos de bases de datos.
¿Qué pasa con findOneBy y los servicios restantes?
El método findOneBy reemplaza al antiguo findOne cuando solo se necesita filtrar por un campo sin relaciones adicionales [04:08]. Se le envía directamente el objeto con la condición:
typescript
const item = await this.repo.findOneBy({ id });
El proceso de migración en los servicios se vuelve metódico: recorrer cada findOne y mover el ID desde el primer parámetro hacia el where [05:50]. Las entidades no requieren cambios; tampoco los controladores, ya que la capa de servicios absorbe toda la actualización.
¿Cómo se migra el HttpModule en NestJS 9?
Otro cambio importante es que HttpModule ya no vive en @nestjs/common [07:35]. Ahora se encuentra en un paquete separado que debe instalarse:
bash
npm install @nestjs/axios axios
Donde antes se importaba HttpService desde @nestjs/common, ahora se importa desde @nestjs/axios. El servicio mantiene el mismo nombre y funcionalidad.
Además, el método toPromise está marcado como deprecated [08:15]. La alternativa recomendada es utilizar lastValueFrom de RxJS:
typescript
import { lastValueFrom } from 'rxjs';
const request = this.httpService.get(url);
const { data } = await lastValueFrom(request);
¿Qué papel juegan las variables de entorno en la migración?
Al levantar el servicio tras la migración, es posible que aparezcan errores relacionados con variables de entorno faltantes [09:05]. Si previamente se implementó validación de configuración —una buena práctica—, el sistema exigirá que variables como API_KEY, DATABASE_NAME, DATABASE_PORT, POSTGRES_USER, POSTGRES_PASSWORD y el HOST estén definidas en el archivo .env.
- Verificar el archivo
docker-compose para obtener los valores correctos.
- Completar tanto las variables de PostgreSQL como las de MySQL si se utiliza el switch de TypeORM.
- Validar todas las variables necesarias en el esquema de configuración para evitar arranques incompletos.
Una vez configuradas, el servicio arranca sin errores de TypeORM ni de configuración [11:30]. Los métodos create, update y delete permanecen exactamente igual; solo las consultas de tipo find y sus variantes requirieron actualización.
Si ya completaste esta migración, comparte qué parte te resultó más repetitiva o si encontraste algún caso particular que no se haya cubierto aquí.
