Lanskap package

Topik sebelumnya menghubungkan dua paket yang ditulis sendiri. Topik ini memperluas pandangannya ke ekosistem, yaitu bagaimana satu package Zig dikenali, dibuat, dan dicari di komunitas. Materinya berbentuk survei, tetapi didasari satu peragaan nyata, yaitu perintah zig init yang menghasilkan kerangka package standar dan menjadi titik awal hampir semua proyek komunitas.

Konsep#

Perintah zig init dijalankan pada direktori kosong dan menghasilkan kerangka proyek lengkap. Susunannya memuat manifest build.zig.zon, graf build build.zig, program utama, dan modul pustaka dengan pemeriksaannya. Susunan ini bukan konvensi semata, karena zig build membaca manifest dan graf build yang dibuat oleh perintah tersebut, dan zig fetch mengenali direktori yang memuatnya sebagai package yang sah.

Perintah-perintah ekosistemnya bekerja atas anatomi yang sama. zig fetch --save <sumber> mengambil package dari URL atau direktori lokal, menghitung hash isinya, lalu menuliskan entri .dependencies pada manifest proyek yang sedang dipakai. zig build --fetch mengambil seluruh dependensi yang sudah dinyatakan, sehingga proses build berikutnya tidak memerlukan jaringan. Kedua perintah mengandalkan hash pada manifest sebagai sumber kebenaran, bukan URL-nya.

Contoh Lengkap#

Kerangka package dihasilkan pada direktori kosong bernama initdemo.

zig init

info: created build.zig
info: created build.zig.zon
info: created src/main.zig
info: created src/root.zig
info: see `zig build --help` for a menu of options

Kelima baris tersebut muncul persis seperti itu, dan empat berkas baru hadir pada direktori. Manifest build.zig.zon hasilnya sudah terisi lengkap, berikut potongan field utamanya yang disalin dari berkas hasil zig init. Komentar dokumentasi yang menyertai tiap field juga dihasilkan oleh perintah tersebut, sehingga manifest baru tetap terbaca maksudnya tanpa membuka dokumentasi luar.

.{
    .name = .initdemo,
    .version = "0.0.0",
    .fingerprint = 0xa5a04b605389bad2,
    .minimum_zig_version = "0.17.0",
    .dependencies = .{},
    .paths = .{
        "build.zig",
        "build.zig.zon",
        "src",
    },
}

Field minimum_zig_version menandai versi toolchain terendah yang didukung paket, dan paths mencantumkan seluruh isi yang ikut terhitung pada hash paket. Graf build hasil zig init juga sudah memuat langkah run dan test, sehingga pemeriksaan bawaan dapat langsung dijalankan pada modul pustakanya.

zig test src/root.zig

1/1 root.test.basic add functionality...OK
All 1 tests passed.

Satu pemeriksaan bawaan berjalan dan lulus, yang membuktikan kerangkanya utuh sejak awal. Dari titik ini, pengembangan package berlangsung dengan mengisi src/root.zig, menambah dependensi melalui zig fetch --save, dan mengekspor modulnya melalui addModule.

Lanskap komunitas#

Sumber package komunitas Zig berubah bentuk pada 2026. Direktori komunitas seperti Zigistry mengumpulkan package beserta klasifikasinya, dan daftar agregat seperti awesome-zig memuat tautan ke proyek berdasarkan kategori. Sebagian besar package dipublikasikan sebagai repositori kode sumber, sehingga konsumsinya selalu melalui manifest dengan .url dan .hash, bukan melalui server paket terpusat. Model ini menempatkan tanggung jawab penilaian pada pembaca manifestnya, karena tidak ada kurator pusat yang menyetujui kualitas sebelum package terdaftar.

Kriteria pemilihan package yang dapat dipertanggungjawabkan mencakup empat hal berikut.

1. Kompatibilitas versi, dibaca dari field minimum_zig_version pada manifestnya, karena Zig pra-1.0 mengubah API antar rilis.
2. Status pemeliharaan, diamati dari repositori Codeberg atau GitHub yang berlaku, bukan dari tautan yang sudah basi.
3. Ketergantungan, karena package tanpa dependensi mudah diaudit dan jarang menimbulkan konflik.
4. Kualitas pemeriksaan, dilihat dari kepadatan blok test pada kode sumbernya.

Membaca manifest package orang lain juga menjadi keterampilan tersendiri. Field .dependencies memperlihatkan rantai ketergantungan yang akan dibawa masuk, field .minimum_zig_version membatasi toolchain yang cocok, dan daftar .paths menunjukkan berkas mana yang benar-benar terhitung dalam paketnya. Ketiganya dibaca dalam hitungan menit dan jauh lebih menentukan daripada halaman dokumentasinya, karena manifest adalah sumber kebenaran yang dipakai build.

Kesalahan umum#

Kesalahan kedua berupa memakai package yang versi Zig minimumnya lebih tinggi atau lebih rendah dari toolchain. Gejalanya berupa pesan error API yang tidak dikenal pada kode dependensi, misalnya field atau fungsi pustaka standar yang berpindah pada rilis baru. Pemeriksaan minimum_zig_version sebelum menambah dependensi memangkas kegagalan ini, dan penyesuaian versi toolchain lokal dilakukan bila diperlukan.

Kesalahan ketiga berupa mengandalkan tautan GitHub lama untuk proyek yang berpindah ke Codeberg. Tautan lama dapat tetap hidup sebagai cermin atau berhenti mutakhir, dan keduanya menyesatkan penilaian pemeliharaan. Pencarian ulang nama proyek pada Codeberg memberikan status yang akurat.

Ringkasan#

• zig init menghasilkan kerangka package standar beserta manifest, graf build, dan pemeriksaan bawaannya.
• zig fetch --save menuliskan dependensi beserta hashnya, dan zig build --fetch menyiapkan seluruhnya untuk build tanpa jaringan.
• Lanskap komunitas bertumpu pada direktori seperti Zigistry dan repositori Codeberg, tanpa server paket terpusat.
• Pemilihan package menilai kompatibilitas versi, pemeliharaan, ketergantungan, dan kualitas pemeriksaannya.

Modul berikutnya adalah penutup jalur, yaitu memilih, merencanakan, dan menuntaskan proyek nyata dengan seluruh perangkat yang telah dibahas.

Referensi#

• Zigistry — Komunitas Zig — Direktori package komunitas Zig beserta klasifikasinya.
• Zig 0.17.0 Release Notes, bagian Package Management — ziglang.org — Perilaku resmi manifest, hash, dan pengambilan dependensi pada 0.17.0.