Zigのパッケージ管理をコンパイラからビルドシステムへ移行
原題: Zig: All Package Management Functionality Moved from Compiler to Build System
なぜ重要か
Zigのビルドシステムとパッケージ管理の分離は、言語エコシステムの保守性と安全性を高め、開発ツールチェーンの成熟を示す重要な設計変更である。
Zigプログラミング言語の作者Andrew Kelleyは2026年6月30日、パッケージ管理に関する全機能をコンパイラ実行ファイルからビルドシステム（makerプロセス）へ移行したと発表した。`zig build`・`zig fetch`・`zig init`・`zig libc`の各サブコマンドがmakerプロセスへ移され、コンパイラのバイナリサイズは14.1 MiBから13.5 MiBへ約4%縮小した。
Zigの開発者Andrew Kelleyは、パッケージ管理ロジック全体をコンパイラ実行ファイルからmakerプロセス（ビルドシステム）へ移行したことを公式Devlogで報告した。
移行されたサブコマンドは`zig build`、`zig fetch`、`zig init`、`zig libc`の4つ。これに伴い、HTTPクライアント・ネットワーキング、TLSおよび関連する暗号処理、Gitプロトコル、xz・gzip・zstd・flate・zipの解析、`build.zig.zon`ファイルの処理など、従来コンパイラに含まれていた大規模なコードがソース形式での配布へ切り替わった。
この変更によりもたらされる主なメリットは以下の通り。まず、コンパイラを再ビルドせずにパッケージ管理機能へパッチを当てられるようになるため、ユーザーや貢献者の開発が容易になる。次に、makerプロセスがReleaseSafeモードでコンパイルされるため、ネットワーク処理においてセーフティチェックが有効になる。さらに、暗号処理やファイルハッシュ計算にホストCPUの特殊命令を活用できるようになる。
プロセスツリーの構造も変化した。従来は「zig build（コンパイラ＋パッケージマネージャ）→ builder（ユーザーのbuild.zigロジック＋ビルドシステム）」という階層だったが、今回の変更後は「zig build（コンパイラ）→ maker（ビルドシステム＋パッケージマネージャ）→ configurer（ユーザーのbuild.zgロジック）」という構造になった。これにより、`zig build --watch`実行時にconfigurererの再実行が必要な場合でも、makerプロセスが親プロセスとして継続稼働できるようになった。
破壊的変更はほぼないが、一部の挙動変更がある。コンパイラバイナリサイズは14.1 MiBから13.5 MiBへ縮小。`--maker-opt`フラグは環境変数`ZIG_DEBUG_MAKER`に、`--zig-lib-dir`フラグは`ZIG_LIB_DIR`に置き換えられた。
Kelleyは今後の課題として、ビルドサーバープロトコルのMVP実装（ZLSのブロック解消に必要）、ビルドスクリプト自体のパス依存関係の導入、`zig build --watch`によるビルドスクリプト変更の検出などを挙げた。7月に2件のカンファレンスへの登壇を控えているため、これらの対応は8月上旬以降になる見通しとしている。