Zig saca los paquetes del compilador

Zig acaba de mover una parte sensible de su diseño: la gestión de paquetes ya no vive dentro del compilador, sino en el sistema de build. Si vienes siguiendo el lenguaje, esto no es un cambio cosmético ni una simple reorganización de comandos. Cambia el lugar donde se resuelven dependencias, cómo se piensa la distribución del código y qué papel cumple cada herramienta en la cadena de desarrollo.

Para ti, esto importa por una razón muy concreta: cuando un lenguaje mezcla compilación, resolución de paquetes y orquestación de proyectos en una sola pieza, te simplifica algunas cosas al inicio, pero también te ata a un modelo único. Zig está empujando en la dirección contraria. La idea es separar responsabilidades y dejar que el build system sea el punto donde decides de dónde salen las dependencias, cómo se integran y qué versión exacta entra en tu proyecto. Según la nota oficial del proyecto, el cambio fue anunciado el 30 de junio de 2026 y forma parte de la evolución del tooling del lenguaje. Puedes leer la fuente aquí: https://ziglang.org/devlog/2026/#2026-06-30

Qué cambió exactamente en Zig

Hasta ahora, la conversación sobre paquetes en Zig estaba muy pegada al compilador. Eso tenía sentido en una etapa temprana del lenguaje: menos piezas, menos conceptos, menos superficie para el usuario. Pero también mezclaba dos problemas distintos. Uno es compilar código. Otro es decidir qué código entra al proyecto, desde dónde se descarga y cómo se versiona.

Con este movimiento, Zig separa esas tareas. El compilador sigue compilando, y el sistema de build asume la gestión de paquetes. En otras palabras, el lenguaje deja de tratar las dependencias como una extensión natural del compilador y pasa a verlas como parte de la definición del proyecto. Ese cambio parece pequeño en una frase, pero en la práctica cambia bastante la experiencia diaria.

La documentación oficial del proyecto ya venía empujando hacia un modelo donde build.zig es el centro de gravedad del proyecto. Si quieres revisar el enfoque general del build system, la referencia oficial está aquí: https://ziglang.org/documentation/master/#Build-System. Ahí se ve que Zig no quiere que tú pienses solo en “compilar archivos”, sino en describir un grafo de pasos, artefactos y dependencias.

Antes: el compilador hacía demasiado

Cuando el compilador se encarga de más cosas de las que debería, aparecen dos efectos conocidos. El primero es que el lenguaje parece más simple desde fuera, porque tienes menos comandos que aprender. El segundo es que cada cambio de diseño toca una capa muy sensible, porque cualquier ajuste en paquetes afecta directamente al compilador, a la CLI y a la forma en que resolvías dependencias.

Ese acoplamiento no solo complica el mantenimiento interno del proyecto. También complica tu trabajo si haces tooling, CI o empaquetado. Si una herramienta quiere inspeccionar dependencias, ya no basta con invocar el compilador y esperar una respuesta limpia. Necesita entender el modelo del build system, que es donde ahora vive la lógica real.

Ahora: el build system manda

La ventaja de mover esta lógica al sistema de build es que Zig puede modelar mejor proyectos reales, no solo ejemplos pequeños. Un proyecto serio casi nunca depende de una sola librería. Suele mezclar código propio, módulos externos, flags de compilación, pasos de generación y, a veces, targets distintos para Linux, Windows o WebAssembly.

En ese contexto, poner la resolución de paquetes en el build system tiene más sentido. Tú defines el proyecto y sus entradas en un solo lugar. El compilador recibe lo que ya fue resuelto. Eso reduce la magia oculta y hace más explícito lo que antes quedaba repartido entre comandos y convenciones.

Por qué Zig tomó esta decisión

Zig lleva tiempo defendiendo una idea bastante clara: el lenguaje debe ser predecible. Eso significa que la compilación no debería depender de comportamientos escondidos, ni de una capa de tooling que inventa reglas por debajo. Si el proyecto crece, tú necesitas ver qué pasa y dónde pasa.

Mover paquetes al build system también encaja con una filosofía más amplia de Zig: el compilador no debería convertirse en una plataforma de orquestación completa. Si todo vive en el binario del compilador, cada nueva función aumenta la complejidad del núcleo. Separar responsabilidades hace que el lenguaje pueda evolucionar sin convertir al compilador en una especie de navaja suiza imposible de mantener.

Además, hay un punto práctico. Las dependencias no son solo “paquetes”. Muchas veces son fuentes, versiones, artefactos y pasos de integración. Un sistema de build puede representar mejor eso que una interfaz pensada solo para compilar. El resultado es un modelo más cercano a cómo trabajan hoy los equipos que usan dependencias externas, CI y reproducibilidad.

Menos magia, más control

Hay una diferencia grande entre “funciona automático” y “sé exactamente qué está pasando”. En proyectos chicos, lo primero suele ganar. En proyectos medianos o grandes, lo segundo termina siendo más valioso.

Con este cambio, Zig te empuja a declarar más explícitamente tus dependencias y tu flujo de build. Eso puede parecer más verboso al principio, pero te da ventajas concretas:

• puedes revisar el proyecto sin depender de una lógica implícita del compilador;
• puedes automatizar pasos en CI con más claridad;
• puedes auditar de dónde sale cada dependencia;
• puedes adaptar el proyecto a distintos targets sin improvisar.

Menos acoplamiento interno

Este tipo de decisión también ayuda al propio lenguaje. Cuando el compilador se libera de tareas de gestión de paquetes, el equipo de Zig puede avanzar en el core sin arrastrar cambios en la capa de distribución. Eso suele traducirse en menos deuda técnica y en una base más fácil de evolucionar.

No significa que todo se vuelve trivial. Significa que cada pieza tiene un rol más claro. Y cuando haces tooling alrededor de un lenguaje, esa claridad vale mucho. Un IDE, un indexador o una herramienta de CI agradecen que la lógica de paquetes no esté escondida dentro de una caja negra llamada “compilador”.

Cómo te afecta si usas Zig en un proyecto real

Si ya estás usando Zig o lo estás evaluando para un servicio, una CLI o una librería, este cambio te toca en varios frentes. El primero es el onboarding. Antes, parte de la historia del proyecto podía parecer “el compilador hace esto por ti”. Ahora, la lógica de dependencias se vuelve más parecida a la de otros ecosistemas donde el build file tiene un rol central.

Eso puede hacer que tu proyecto sea más entendible para equipos que vienen de Rust, CMake o incluso JavaScript, donde el manifiesto o el build script es el lugar natural para resolver dependencias. La diferencia es que Zig intenta mantener su estilo minimalista y no copiar un gestor de paquetes pesado.

También cambia tu forma de pensar la reproducibilidad. Si el build system es el dueño de las dependencias, puedes fijar mejor qué versión entra, cómo se obtiene y bajo qué condiciones se compila. Para equipos en LatAm, donde a veces la conectividad no es estable o los mirrors no siempre responden igual, eso no es un detalle menor. Tener un build más explícito ayuda a reducir sorpresas.

Ejemplo práctico: una librería interna y una externa

Imagina que mantienes una API en Zig para una empresa en Quito, y esa API depende de una librería interna de validación más una librería externa para parsing JSON. Con el nuevo enfoque, tu build.zig se vuelve el lugar donde declaras esas piezas. No esperas que el compilador adivine nada.

Eso te permite hacer cosas como estas, a nivel conceptual:

1. declarar el módulo principal del proyecto;
2. registrar una dependencia externa con una versión fija;
3. enlazar el módulo interno de validación;
4. definir el ejecutable final;
5. configurar pasos de test y build por target.

Ese flujo es más largo que un comando mágico, sí. Pero también es más fácil de revisar en code review y más fácil de automatizar en CI.

Tabla: qué ganas y qué pierdes con el cambio

La tabla no significa que todo sea mejor automáticamente. Significa que el costo se mueve. Aprendes un poco más al inicio, pero ganas control y claridad cuando el proyecto crece.

Qué implica para el tooling y el ecosistema

Este cambio no solo toca a quien escribe código. También afecta a quienes construyen herramientas alrededor de Zig. Si una función ya no vive en el compilador, cualquier integrador, editor o sistema de automatización debe mirar al build system para entender dependencias y pasos del proyecto.

Eso puede ser bueno si quieres una arquitectura más limpia. Un IDE, por ejemplo, puede apoyarse en el build script para inferir módulos y rutas con menos ambigüedad. Un sistema de CI también puede leer la definición del proyecto y ejecutar pasos de forma más predecible. Pero hay una condición: el build system tiene que ser suficientemente claro y estable para que el ecosistema no termine peleando con él.

En lenguajes que han crecido rápido, esta separación suele aparecer tarde o temprano. Rust tiene Cargo como pieza central. Go simplificó mucho la historia del empaquetado, aunque también hizo ciertos trade-offs. Zig está eligiendo un camino donde el compilador se mantiene delgado y el build system gana peso. No es una copia de nadie, pero sí una señal de hacia dónde quiere ir el proyecto.

Lo que esto puede mejorar

Hay varias áreas donde este cambio puede darte mejores resultados:

• integración con CI/CD más clara;
• proyectos multi-target más ordenados;
• dependencias fijadas con más precisión;
• menos lógica oculta en el compilador;
• mejor base para tooling de terceros.

Si trabajas en una empresa con varios repositorios, esto también ayuda a estandarizar. Puedes definir una forma común de traer dependencias y construir binarios, en vez de depender de hábitos personales o scripts sueltos.

Lo que te obliga a revisar

También hay costos. El primero es que tendrás que aprender mejor el build system de Zig. Si antes te apoyabas en una capa más automática, ahora tendrás que entender cómo se declaran paquetes, módulos y pasos de build.

El segundo es que tu documentación interna puede quedarse vieja rápido. Si tu equipo tiene guías que hablan de paquetes como si fueran parte del compilador, vas a tener que actualizarlas. En migraciones de tooling, ese tipo de detalle genera más fricción de la que parece.

Cómo leer este cambio sin exagerarlo

No estamos ante un cambio que destruya la experiencia de Zig. Tampoco ante una simple reubicación de archivos. Lo que pasó es más profundo: el lenguaje está redefiniendo dónde vive la complejidad. Eso suele ser una buena señal cuando un proyecto madura.

Si tú vienes de ecosistemas donde el build file ya es la unidad central de configuración, este cambio te va a parecer natural. Si vienes de ver a Zig como un lenguaje muy directo y compacto, quizá notes más fricción al principio. Ambas lecturas son válidas.

Lo útil aquí es entender la dirección: Zig quiere separar compilación de orquestación, y quiere que las dependencias sean parte del proyecto, no del compilador. Eso hace al lenguaje más coherente con proyectos reales y, al mismo tiempo, más exigente con quien lo usa.

Qué deberías hacer ahora

Si estás evaluando Zig para un proyecto nuevo, te conviene revisar tres cosas antes de decidir:

1. cómo vas a declarar dependencias en el build system;
2. qué tan cómodo te resulta mantener esa definición en CI;
3. si tu equipo acepta una curva de aprendizaje algo mayor a cambio de más control.

Si ya tienes un proyecto en Zig, haz una revisión de tu build.zig y de tu estrategia de dependencias. Pregúntate si hoy dependes de supuestos antiguos sobre el compilador. Si la respuesta es sí, este es un buen momento para ordenar eso.

Tabla resumen

En la práctica, este movimiento te obliga a pensar Zig de otra manera: menos como un compilador con extras y más como un lenguaje donde el proyecto se describe de forma explícita. Si tu trabajo depende de builds reproducibles, dependencias claras y tooling que no se rompa por magia interna, este cambio te conviene mirarlo de cerca.