vlt – instala paquetes npm sin ejecutar scripts de instalación

Cuando escribes npm install, los paquetes que llegan pueden ejecutar scripts de instalación en tu máquina antes de que hayas leído una sola línea de su código. Es el vector de los ataques a la cadena de suministro más comunes del ecosistema JavaScript. vlt, el gestor de paquetes creado por los autores originales de npm, salió el 7 de septiembre en su versión 1.0 con una propuesta concreta: nada se ejecuta en tu máquina solo porque escribiste install. Aquí vas a ver cómo funciona, cómo migrar desde npm, y —lo más importante— los criterios para decidir si te conviene a ti.

El problema que resuelve

Un paquete npm puede declarar scripts de ciclo de vida (postinstall, prepare) que se ejecutan automáticamente durante la instalación. En teoría sirven para compilar binarios nativos o preparar assets. En la práctica, cualquier paquete que instales puede correr código arbitrario con tu usuario.

No es teórico: los ataques de cadena de suministro via postinstall llevan años apareciendo, y el tamaño del problema se mide en cientos de miles de versiones marcadas.

Cómo instala vlt: por fases

La diferencia estructural con npm es que la instalación está partida en dos comandos:

vlt install   # descarga y extrae los paquetes, no ejecuta nada
vlt build     # ejecuta solo los scripts de los paquetes en los que confías

vlt install trae todo a tu disco sin correr un solo script. vlt build ejecuta los scripts aprobados y bloquea por defecto cualquier paquete marcado como malware. Es decir: la decisión de ejecutar código pasa de «automática» a «explícita».

Además, los registros alojados de vlt rechazan los paquetes maliciosos conocidos antes de servirlos — el bloqueo ocurre en el registro, no solo en tu máquina. Más de 275.000 versiones están marcadas, y según los revisores, una cuarta parte de ellas sigue siendo instalable desde npm.

Consultas de grafo con vlt query

La pieza más interesante para equipos: vlt query trata tu grafo de dependencias como un árbol consultable con más de 60 selectores de estilo CSS, y cerca de la mitad son de seguridad:

vlt query ':has(@types/*)'

El catálogo de selectores está orientado a auditar a escala, con la integración de Socket detrás. Dos extras que valen la pena conocer:

• :host(local) extiende la consulta a todos los proyectos de tu máquina, no solo al directorio actual.
• --view=mermaid devuelve el resultado como un diagrama de Mermaid, para pegarlo en documentación o revisarlo en una reunión.

Cómo migrar desde npm

El punto de partida de vlt es que es un reemplazo directo: la API de registro es compatible con npm, así que tus pipelines de CI, registros privados y tooling siguen funcionando sin cambios.

npm install -g vlt

Después, dentro de tu proyecto:

vlt install
vlt build

Lo que cambia en el proyecto:

• La configuración migra de .npmrc a vlt.json.
• El lockfile nuevo se llama vlt-lock.json — tu package-lock.json deja de usarse, así que decide cómo quieres manejar la transición si tu equipo comparte lockfiles.

Criterios para decidir, no una respuesta única

vlt no es el único que se ha movido hacia acá, y ser honesto con el contexto importa más que la recomendación:

• npm v12 también desactiva los scripts de instalación por defecto.
• pnpm pone en cuarentena los releases muy recientes con una antigüedad mínima.
• Bun bloquea los scripts postinstall.

Lo genuinamente distinto de vlt es el bloqueo a nivel de registro — los otros actúan en tu máquina. Y en velocidad pura de instalación, pnpm y Bun siguen adelante; vlt afirma un registro hasta 38% más rápido que el de npm, no ser el más rápido en general.

Entonces, según tu caso:

• Equipo con grafo grande de dependencias y auditoría frecuente: vlt es el caso claro — las consultas de grafo y el bloqueo en registro son valor real.
• Ya estás a gusto con pnpm o Bun y su manejo de scripts: el valor marginal está en vlt query y en el registro; puede no justificar la migración hoy.
• Proyecto pequeño o personal: npm install -g vlt y probarlo cuesta cinco minutos; el lockfile distinto es lo único que se queda en tu repo.

Cómo verificar la decisión por tu cuenta

Nada de creerle a un artículo, ni siquiera a este:

• Instala vlt en un proyecto real con npm install -g vlt y corre vlt install — compara con tu lockfile actual.
• Corre vlt query con un par de selectores de seguridad y mira qué encuentra en tu grafo hoy. Ese resultado es el argumento más honesto a favor o en contra.
• Mide el tiempo de instalación contra el de tu gestor actual en tu máquina, no en benchmarks.

Fuente: el anuncio de vlt 1.0 en InfoQ, con los detalles de las instalaciones por fases, las consultas de grafo y el contexto del resto del ecosistema.