build.zig.zon y el gestor de paquetes

Beside build.zig sits build.zig.zon, the manifest that names your package and lists what it depends on. 📜

The file is written in ZON, which looks just like a Zig anonymous struct literal. Dotted field names map to plain Zig values.

Two required fields stand out: name identifies the package and version follows semantic versioning like 1.2.0.

The dependencies field is a struct of entries, one per external package you want to pull into your build.

Each dependency gives a url to a tarball, usually a tagged archive on a code host. Zig fetches and unpacks it for you.

A hash field pins the exact bytes of that download. If the content ever changes, the hash mismatches and the build refuses it.

You rarely type a hash by hand. Run zig fetch with the url and it downloads, computes the hash, and writes the entry for you.

Fetched packages land in a shared cache on your machine. Many projects reuse one copy, so the same dependency is not stored twice.

The paths field lists the files included when your package is itself a dependency. Use .{""} to ship everything in the folder.

Because it carries exact hashes, build.zig.zon makes builds reproducible. Commit it so every teammate fetches the identical code.

The manifest pairs with build.zig, which turns each declared dependency into a usable module. The .zon describes, the build script wires.

Recall what guarantees a dependency download has not been tampered with.

You met build.zig.zon: a ZON manifest with name, version, and dependencies, where each dep carries a url and a hash that zig fetch can fill in. 🎯