Skip to main content
Traducción. Autoritativo: ../../standards/dependencies.md.

​
1. La regla de cuarentena

Una versión publicada DEBE tener al menos 2 días de antigüedad antes de poder instalarse o commitearse. Sin excepción por conveniencia, urgencia ni por ser “solo un patch”. La razón es concreta: el vector de ataque de supply chain es la versión recién publicada. Un release comprometido se detecta y se retira típicamente en horas o días, así que la ventana de días es donde vive el peligro. Esperar no cuesta nada y elimina la clase completa. La única excepción: una versión que corrige un aviso de seguridad que nos afecta se salta la cuarentena y sale de inmediato. La seguridad gana sobre la precaución respecto de la seguridad — pero el salto queda registrado en el PR con el id del aviso. Impuesto por renovate.json (minimumReleaseAge: "2 days"). El enforcement no reemplaza la regla: un pnpm add manual de un release del mismo día viola este estándar aunque nada lo bloquee.

​
2. Pineo

  • Versiones exactas en todas partes. Sin ^, sin ~, sin rangos (save-exact=true en .npmrc).
  • El lockfile se commitea y se revisa como código. Un diff de lockfile sin explicación bloquea un PR.
  • packageManager y .nvmrc fijan el toolchain; se actualizan por el mismo proceso.

​
3. Adopción

La última estable en el momento de adoptar. Cuando una dependencia entra al repositorio, entra en su release estable actual — nunca en una versión más antigua “por si acaso”, nunca en un prerelease, alpha, beta, canary, rc ni tag next. Dos matices que “latest” por sí solo no captura:
  • La alineación de major con el par gana sobre el latest absoluto. @types/node sigue el major de Node que efectivamente corremos (Node 24 ⇒ @types/node 24.x), sin importar a qué apunte latest. La misma lógica aplica a cualquier paquete cuyo major esté acoplado a un runtime o framework.
  • Una dependencia 0.x no tiene API estable. En 0.x un bump de minor puede romper. Todo paquete 0.x en un camino crítico (hoy: drizzle-orm) se actualiza deliberadamente, con su propio PR y su propia pasada de tests — nunca agrupado, nunca con automerge.
Una dependencia sin mantención, o cuya última estable sea lo bastante vieja como para estar abandonada, no se adopta. Ese juicio pertenece al ADR que la introduce.

​
4. Introducir una dependencia

El stack es cerrado. Una dependencia o vendor nuevo exige un ADR antes del primer import (AGENTS.md §2.2). El ADR declara qué reemplaza o habilita, por qué perdieron las alternativas, sus señales de mantención, su licencia y —para todo lo que toque datos personales— si se convierte en subencargado que exige entrada en docs/internal/legal/subprocessors.md. Actualizar una dependencia existente nunca necesita ADR. Reemplazar una siempre lo necesita.

​
5. Mantenerse al día

Una ventana trimestral maneja los majors acumulados con un responsable nombrado. Los majors no derivan: un major sin aplicar por más de dos trimestres se vuelve deuda registrada, porque el costo de ponerse al día crece más rápido que el de mantenerse al día.

​
6. Gates de CI

  • pnpm audit --audit-level=high falla el build. Un hallazgo se arregla o se exceptúa explícitamente con fecha de vencimiento — nunca indefinidamente.
  • Chequeo de deriva del lockfile: debe estar sincronizado con los manifiestos.
  • Ningún especificador de prerelease en ningún manifiesto.
  • Allowlist de licencias: las copyleft incompatibles con un producto propietario se rechazan en CI, no se descubren en una due diligence.

​
7. Toolchain actual y sus actualizaciones pendientes

Adoptar TypeScript 7 es un spike, no un bump. “Es la última” no es razón para adoptar una reescritura del compilador antes de que el toolchain que lo consume la haya certificado.