Devlog<br>Zig Programming Language
Download
Learn
News
Source<br>Join a Community
Zig Software Foundation
Devlog
Devlog
This page contains a curated list of recent changes to main branch Zig.
Also available as an<br>RSS feed.
This page contains entries for the year 2026. Other years are available in<br>the Devlog archive page.
June 30, 2026<br>All Package Management Functionality Moved from Compiler to Build System
Author: Andrew Kelley<br>Now that there is a separate process for users’ build.zig scripts and the build system itself, it makes sense for that to be the place that package management logic lives.<br>I moved these subcommands to the maker process:<br>zig build<br>zig fetch<br>zig init<br>zig libc<br>This means that large parts of what used to be included in the compiler executable are now shipped in source form instead, including:<br>package fetching logic<br>HTTP client and networking<br>TLS (Transport Layer Security) and associated crypto<br>Git protocol<br>xz, gzip, zstd, flate, zip<br>parsing, validation, and otherwise dealing with build.zig.zon files<br>Consequently, this functionality can now be patched without rebuilding the compiler, making it easier for users and contributors to tinker.<br>Furthermore, it means that package management in zig now has safety checks enabled when doing networking, since the maker executable is compiled in ReleaseSafe mode. Plus, all the crypto used for networking and file hashing can now take advantage of special CPU instructions available on the host, even the ones that are too rare to normally depend on when distributing software. We can have AOT cake and eat JIT, too!<br>My original motivation for doing this was in relation to exposing a build server protocol in order to unblock ZLS after maker/configurer process separation made breaking changes to the --build-runner override flag.<br>Originally, the process tree looked like this:<br>zig build (the zig compiler + package manager)<br>└─ builder (the user's build.zig logic + build system implementation)<br>The process separation changeset made it look like this instead:<br>zig build (the zig compiler + package manager)<br>├─ configurer (the user's build.zig logic)<br>└─ maker (build system)<br>At this point, consider a long-running zig build --watch process, watching files and rebuilding on source code changes. If any changes to build.zig are detected, or any files observed during execution of that logic, it means configurer needs to be rerun, meaning that maker process must exit to give zig build a chance to repeat the package management logic.<br>Now, after the changes described in this devlog entry, it looks like this:<br>zig build (the zig compiler)<br>└─ maker (build system + package manager)<br>└─ configurer (the user's build.zig logic)<br>Thus, when configuration needs to be rerun, maker process can continue to live because it is the parent process rather than a sibling. In terms of the upcoming build server, it means avoiding an awkward situation where the server has to exit and the client has to reconnect, rather than simply informing the client of a configuration change.<br>This is almost entirely a non-breaking change, but there are some observable differences:<br>Zig executable binary size: shrinks 4% from 14.1 to 13.5 MiB (no LLVM, ReleaseSmall)<br>--maker-opt flag is replaced by ZIG_DEBUG_MAKER environment variable<br>--zig-lib-dir flag is replaced by ZIG_LIB_DIR environment variable<br>The follow-up issues to this changeset are the main blockers until we tag Zig 0.17.0:<br>build server protocol MVP (needed to unblock ZLS)<br>introduce the concept of adding path dependencies of the build script itself<br>make zig build --watch detect modifications to the build script and rerun itself<br>different cwd causes build script cache miss<br>I have two conferences coming up in July and I need to work on my talks, so being realistic, I don’t think I will have time to wrap these up until early August. Contributions welcome, of course.<br>Big thanks to Techatrix from the ZLS team for reaching out and working with me on the build server protocol! They are seeking sponsorship, by the way.
June 26, 2026<br>SPIR-V Backend Progress
Author: Ali Cheraghi<br>There’s quite a bit to cover. The SPIR-V backend had bitrotted in a number of places after the recent compiler changes, so I spent the past several weeks dragging it into a better state.<br>@SpirvType<br>SPIR-V has a handful of types that couldn’t be expressed in Zig’s type system. The new @SpirvType builtin has been introduced to address the longest-standing blocker for writing shaders. See #20550, #23326 and #35461 to trace the background.<br>const Sampler = @SpirvType(.sampler);<br>const Image = @SpirvType(.{ .image = .{<br>.usage = .{ .sampled = u32 },<br>.format = .unknown,<br>.dim = .@"2d",<br>.depth = .unknown,<br>.arrayed = false,<br>.multisampled = false,<br>.access = .unknown,<br>} });<br>const SampledImage = @SpirvType(.{ .sampled_image = Image });<br>const RuntimeArray = @SpirvType(.{ .runtime_array = u32 });<br>const sampled_image = @extern(*addrspace(.constant) const SampledImage, .{<br>.name =...