La 4.0.0 de ddd-lib es la primera con pruebas sobre las clases que extiendes, y llegar ahí destapó 34 defectos. Arreglarlos cambió comportamiento observable en ocho sitios. El compilador no detecta ninguno de los ocho, así que no hay nada que buscar: hay que repasarlos.
Antes: si vienes de 2.x
- if (!aggregate.isValid()) {
+ if (!aggregate.isValid) {Ése sí lo encuentra el compilador (TS6234). Si consumes desde JavaScript, npx ddd validate señala cada llamada leyendo cómo lo declara tu versión instalada. La historia completa de por qué esto pudo pasar desapercibido está en El guard que nunca se disparó.
Los ocho de la 4.0.0
| # | Qué cambió | Qué hacer |
|---|---|---|
| 1 | validate() limpia las reglas antes de re-derivarlas | Quita tu apaño con brokenRules.clear(). Ahora sobra |
| 2 | clone() y getCopy() devuelven copias reales | Si dependías de que compartieran estado, eso era el bug. Vuelve a suscribir los manejadores en la copia |
| 3 | IdValueObject canonicaliza los UUID a minúsculas | Pasa a minúsculas los guardados, o espéralos así al leer |
| 4 | Las opciones de StringValueObject ya se aplican | allowEmpty, trimWhitespace, minLength, maxLength se ignoraban. Valores que pasaban pueden fallar ahora |
| 5 | IdValueObject.setValue() lanza si no es UUID | Antes lo aceptaba en silencio. Revisa dónde construyes ids |
| 6 | DddEnum.getAll() devuelve un array nuevo | getAll() === getAll() ya no es cierto. Compara contenidos |
| 7 | El comparador de estado recibe (definedState, queryState) | Si tienes uno propio, revisa el orden de los argumentos |
| 8 | La detección de cambios anidados se dispara | Tus repositorios pueden ver escrituras que antes se saltaban |
El orden en que repasarlos
Los tres primeros son los que más gente tiene. El 1 porque el apaño de clear() era la forma habitual de sortear el bug, y ahora limpia dos veces —inofensivo, pero es código muerto que conviene borrar mientras te acuerdas de por qué estaba.
El 3 es el que puede morder en producción sin avisar: si tienes UUIDs guardados en mayúsculas y el código nuevo los canonicaliza a minúsculas, una búsqueda por id deja de encontrar filas. No falla: no encuentra. Que es peor.
El 4 es el que más ruido hace en los tests, y es ruido bueno: valores que llevaban tiempo colándose empiezan a fallar. Si te aparecen fallos nuevos ahí, no los silencies — mira qué estaba pasando.
Cómo comprobarlo
npm i @nestjslatam/ddd-lib@4.0.0
npx ddd validate # audita contra la versión que acabas de instalar
npm testddd validate lee los .d.ts de tu node_modules, así que audita contra la versión real y no contra una tabla de compatibilidad que alguien tendría que mantener al día.
Y clava la versión
Sin ^. La promesa es que a partir de la 4.0.0 no habrá cambios incompatibles sin un ciclo de obsolescencia. Esa promesa se gana a lo largo de un ciclo de versiones, no anunciándola — júzgala en la 4.1.0.
El CHANGELOG explica el razonamiento de cada cambio, y la referencia de API tiene la tabla de qué cambió entre versiones.