Belajar Rust - Paket, Crate, dan Dependency Management

#Pendahuluan

Sejauh ini kita bekerja dengan satu crate kecil. Aplikasi nyata jauh lebih besar: puluhan dependency, beberapa binary dan library, serta kebutuhan untuk memverifikasi bahwa semuanya aman. Episode 7 membahas pengelolaan itu semua dengan cargo.

Kalian akan menyusun Cargo.toml dengan benar, memahami features dan semver, membangun workspace multi-crate, lalu mengamankan rantai dependency dengan cargo audit. Di akhir episode, project Rust kalian siap tumbuh menjadi codebase yang terorganisir.

#Menyusun Cargo.toml

#Manifest dan Bagian-Bagiannya

Cargo.toml adalah pusat konfigurasi package. Bagian [package] mendeklarasikan metadata, sedangkan [dependencies] mencantumkan crate eksternal dengan versi semver.

[package]
name = "aplikasi"
version = "0.1.0"
edition = "2024"
 
[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1.40", features = ["full"] }

Versi 1.40 mengikuti semver: cargo mengizinkan semua versi yang kompatibel ke atas dalam major yang sama. Cargo.lock kemudian mematok versi persis untuk build yang reproducible. Perintah cargo add mengelola bagian ini secara otomatis:

cargo add serde --features derive
cargo add tokio --features full

cargo add serde --features derive menambahkan serde dengan feature derive aktif. Cargo.lock diperbarui, dan seluruh tim mendapat versi yang sama.

#Features: Kumpulan Dependency Opsional

Features adalah mekanisme conditional compilation: dependency atau kode tertentu hanya diaktifkan saat feature diaktifkan. Ini memungkinkan satu crate melayani banyak kebutuhan tanpa membebani pemakai.

[features]
default = ["api"]
api = ["dep:axum"]
cache = ["dep:redis"]
 
[dependencies]
axum = { version = "0.8", optional = true }
redis = { version = "0.27", optional = true }

Feature api dan cache menghidupkan dependency masing-masing. Pemakai hanya membayar untuk fitur yang dipakai. cargo tree --features api menampilkan dependency yang aktif untuk kombinasi feature tertentu.

#Versi Dependency dan Resolusi

#Memahami Semver di Ekosistem Cargo

Cargo memakai semantic versioning: major.minor.patch. Update patch dan minor kompatibel, perubahan major bisa memecah API. Cargo juga mendukung range seperti 1.2, >=1.3, <2.0, atau versi persis =1.2.3.

cargo tree
cargo tree -i axum

cargo tree menampilkan seluruh dependency dan versinya. cargo tree -i axum menjawab pertanyaan "siapa yang memakai axum dan kenapa". Saat ada dependency yang ditarik berlapis, pohon ini menjadi peta untuk resolusi konflik.

#Memperbarui Dependency

cargo update
cargo outdated

cargo update memperbarui versi dalam rentang yang diizinkan Cargo.lock. cargo outdated (dari cargo install cargo-outdated) menampilkan dependency yang ketinggalan. Keduanya bagian dari rutinitas pemeliharaan rutin.

#Workspace Multi-Crate

#Mengapa Workspace

Untuk aplikasi besar, pecah menjadi beberapa crate dalam satu workspace: shared compilation cache, satu Cargo.lock, dan versioning terpadu. Struktur umum: satu workspace dengan crates/ berisi crate binary dan library.

[workspace]
members = ["crates/domain", "crates/api", "crates/cli"]
resolver = "2"
 
[workspace.package]
version = "0.1.0"
edition = "2024"

Setiap crate di members punya Cargo.toml sendiri, dan bisa bergantung satu sama lain lewat path:

cargo add --path crates/domain --package crates/api

cargo add --path crates/domain --package crates/api menambahkan dependency lokal antar crate. cargo build dari root membangun seluruh workspace. cargo run -p crates/cli menjalankan binary tertentu.

#Keamanan Dependency dengan Cargo Audit

#Memindai Kerentanan

Ekosistem crate terbuka, tetapi juga bisa memuat kerentanan. cargo audit memindai Cargo.lock terhadap database kerentanan RustSec:

cargo install cargo-audit
cargo audit

cargo audit menampilkan kerentanan dengan severity, package, versi aman, dan referensi advisory. Ini harus menjadi bagian dari CI, bukan hanya rutinitas lokal.

#Praktik Keamanan Dependency

Beberapa kebiasaan yang menjaga rantai dependency tetap aman:

• Selalu jalankan cargo audit di CI, dan gagalkan build saat ada advisory kritikal.
• Gunakan cargo deny untuk menerapkan kebijakan lisensi dan duplicate dependency.
• Pin dependency berisiko tinggi dan tinjau sebelum update major.
• Hindari --git dependency kecuali benar-benar perlu, karena tidak ada checksum yang stabil.

#Penutup

Inti yang harus dibawa pulang:

• Cargo.toml mendeklarasikan package, dependency, dan features; Cargo.lock mematok versi.
• Semver menentukan rentang versi yang diizinkan cargo.
• Features mengaktifkan dependency dan kode secara kondisional.
• Workspace multi-crate memecah aplikasi besar dengan satu lockfile.
• cargo audit memindai kerentanan; cargo deny mengelola kebijakan.
• Rutin perbarui dependency dan periksa duplicate dengan cargo tree -d.

Di episode 8 selanjutnya kita akan membahas data serialization, persistence, dan I/O — serialisasi dengan serde untuk format JSON dan TOML, I/O file dan async I/O dengan tokio, serta integrasi database dengan sqlx, diesel, atau sea-orm. Kalian akan mulai menyimpan dan memuat data.