Apa Itu TOML? Bahasa Konfigurasi yang Mengalahkan YAML
Apa Sebenarnya TOML Itu
TOML adalah singkatan dari Tom's Obvious, Minimal Language. Penciptanya, salah satu pendiri GitHub Tom Preston-Werner, sudah muak dengan format konfigurasi yang ada pada tahun 2013. Bahasa ini matang selama hampir delapan tahun sebelum rilis stabil pertamanya, TOML v1.0.0, tiba pada Januari 2021. Periode penyempurnaan yang panjang itu menunjukkan betapa seriusnya desainnya dipertimbangkan. Pada intinya, TOML adalah format file konfigurasi. Ini bukan format serialisasi data tujuan umum seperti JSON, juga bukan bahasa markup. Seluruh tujuannya adalah agar mudah dibaca dan ditulis oleh manusia, sambil memetakan secara jelas ke tabel hash—atau apa yang mungkin kamu sebut kamus, peta, atau objek dalam bahasa pilihanmu. File TOML minimal sangat sederhana: ``` title = "My Application" version = "2.4.1" debug = false [database] host = "localhost" port = 5432 max_connections = 100 ``` Setiap nilai memiliki tipe yang eksplisit. `"localhost"` adalah string. `5432` adalah integer. `false` adalah boolean—bukan string `"false"`, bukan `0`, dan bukan `null`. Ketegasan ini adalah inti permasalahannya, dan ini adalah alasan utama para pengembang memilih TOML. Kamu tidak akan pernah membuang waktu bertanya-tanya apakah nomor port-mu akan diurai sebagai string atau integer karena adanya keanehan dalam pustaka YAML tertentu.
Mengapa YAML Menjadi Masalah yang Patut Diselesaikan
YAML mendapat banyak pujian karena ramah pengguna. Untuk file kecil, itu benar. Tapi keramahannya cepat hilang seiring pertumbuhan konfigurasi kamu, dan pilihan desainnya mulai menimbulkan masalah. Contoh paling terkenal adalah Masalah Norwegia (Norway Problem). Dalam YAML 1.1—yang masih menjadi default untuk banyak parser—kode negara dua huruf `NO` diurai sebagai nilai boolean `false`. Konfigurasi seperti `country: NO` akan merusak data kamu secara diam-diam. Ini berlaku untuk `yes`, `no`, `on`, `off`, `true`, dan `false` dalam berbagai kapitalisasi. YAML 1.2 memperbaiki ini, tetapi kamu tidak selalu bisa mengontrol versi parser mana yang digunakan alat-alatmu. Lalu ada spasi signifikan. YAML menggunakan indentasi untuk mendefinisikan struktur, jadi satu spasi yang salah tempat dapat secara diam-diam mengubah seluruh makna file kamu atau bahkan merusaknya sepenuhnya. Siapa pun yang pernah menghabiskan waktu berjam-jam men-debug pipeline CI/CD hanya untuk menemukan inkonsistensi dua-spasi versus empat-spasi tahu betul rasa sakit ini. YAML juga menawarkan terlalu banyak cara untuk menulis hal yang sama. Scalar bisa berupa plain, single-quoted, double-quoted, atau block style. Sequence bisa berupa flow atau block style. Fleksibilitas ini terdengar bagus, tetapi itu berarti dua developer akan menulis konfigurasi logis yang sama dengan cara yang sangat berbeda, membuat diff lebih sulit dibaca dan code review kurang efektif. Ini tidak membuat YAML tidak berguna. Ini adalah standar untuk manifest Kubernetes dan alur kerja GitHub Actions karena suatu alasan. Tetapi untuk konfigurasi aplikasi, di mana kebenaran dan prediktabilitas lebih penting daripada apa pun, keanehan-keanehan ini adalah kerugian serius.
Bagaimana TOML Menyelesaikan Masalah Keterbacaan
Filosofi TOML sederhana: harus ada satu, dan hanya satu, cara yang jelas untuk menulis sesuatu. Kedengarannya membatasi, tetapi hasilnya adalah file konfigurasi yang terlihat dan terasa sama, tidak peduli siapa yang menulisnya atau proyek apa pun yang menjadi bagiannya. Ini menawarkan enam tipe skalar: string, integer, float, boolean, offset date-time, dan local date. Dukungan kelas satu TOML untuk tanggal dan waktu dalam format RFC 3339 adalah fitur yang luar biasa. Kamu bisa menulis `created_at = 2024-03-15T09:30:00Z` dan percaya itu akan menjadi objek datetime yang tepat, bukan string yang harus kamu uraikan sendiri. Meskipun YAML dapat merepresentasikan tanggal, perilakunya tidak konsisten di berbagai parser. Struktur didefinisikan dengan tabel (bagian) dan array tabel. Sebuah tabel mendapatkan header dalam kurung siku: `[server]`. Sebuah array tabel menggunakan kurung siku ganda: `[[products]]`. Sintaksnya tidak ambigu dan mudah dikenali. Berikut adalah contoh nyata dari file `Cargo.toml` Rust, yang menunjukkan bagaimana dependensi didefinisikan: ``` [dependencies] serde = { version = "1.0", features = ["derive"] } tokio = { version = "1", features = ["full"] } reqwest = "0.12" ``` Sintaks tabel inline—bagian dalam kurung kurawal—sangat bagus untuk definisi yang sederhana dan ringkas. Untuk data bersarang yang lebih kompleks, kamu menggunakan header tabel penuh. Bahasa ini memberimu aturan yang jelas kapan harus menggunakan setiap gaya. Bahkan komentar dirancang agar familiar. Mereka menggunakan karakter `#`, sama seperti skrip Python dan shell. Sebagian besar developer sudah mengetahui sintaksnya tanpa perlu membaca satu baris pun spesifikasi.
Di Mana TOML Telah Menang: Angka Adopsi Nyata
Ekosistem Rust adalah kisah sukses terbesar TOML. Cargo, package manager Rust, mewajibkan TOML untuk manifest-nya. Dengan lebih dari 150.000 package di crates.io pada awal tahun 2025, setiap satu di antaranya memiliki file `Cargo.toml`. Itu adalah uji stres dunia nyata yang masif yang hanya sedikit format yang pernah berhasil melaluinya. Adopsi Python melalui PEP 518 (2016) dan PEP 621 (2021) mengukuhkan `pyproject.toml` sebagai satu-satunya tempat yang tepat untuk metadata proyek dan konfigurasi build. Alat-alat seperti Poetry, Hatch, Flit, dan PDM semuanya menggunakannya. Pengaturan linter kamu masuk ke `[tool.ruff]`, pengaturan tes kamu di `[tool.pytest.ini_options]`. Kamu mendapatkan satu file dan satu format untuk menguasai semuanya. Hugo, generator situs statis yang populer, menjadikan TOML sebagai format konfigurasi default-nya, beralih dari YAML dan JSON. Tim secara khusus menyebutkan kejelasan TOML dan tidak adanya paksaan tipe yang mengejutkan sebagai motivasinya. Ketika sebuah bahasa menambahkan parser ke pustaka standarnya, kamu tahu format itu telah tiba. Python melakukan hal itu dengan menambahkan `tomllib` pada versi 3.11 (dirilis Oktober 2022), memungkinkan kamu mengurai file TOML di instalasi Python modern mana pun tanpa dependensi eksternal. Ini bukan hanya masalah Python dan Rust. Go, .NET, dan JavaScript semuanya memiliki pustaka TOML yang matang dan terawat dengan baik. Paket `@iarna/toml` di npm, misalnya, melihat jutaan unduhan setiap minggu. TOML secara resmi sudah mainstream.
Keterbatasan Nyata TOML
Tidak ada alat yang sempurna, dan TOML tidak terkecuali. Penting untuk jujur tentang keterbatasannya agar kamu tahu kapan harus mencari alternatif lain. Data bersarang yang sangat dalam adalah titik lemah TOML. Jika kamu membutuhkan lebih dari dua atau tiga level bersarang, sintaksnya menjadi menyakitkan. Kamu akan menemukan dirimu menulis kunci panjang dengan titik seperti `[servers.production.database.replica]`. Itu valid, tetapi tidak mudah dibaca. JSON dan bahkan YAML lebih baik dalam hal ini karena mereka dibangun untuk representasi data umum. Array besar objek kompleks adalah titik lemah lainnya. Sintaks `[[products]]` untuk array tabel berarti kamu harus mengulang header itu untuk setiap item. Daftar 50 produk menghasilkan 50 header `[[products]]` yang terpisah. Pada titik itu, kamu tidak sedang menulis file konfigurasi; kamu menggunakan alat yang salah. Kamu seharusnya menggunakan JSON atau database. TOML tidak memiliki dukungan untuk anchor dan alias, fitur yang disediakan YAML dengan `&anchor` dan `*alias`. Ini berarti kamu tidak dapat mendefinisikan blok pengaturan sekali dan menggunakannya kembali di seluruh file kamu. Jika kamu perlu mengulang konfigurasi, kamu memiliki dua pilihan: menduplikasinya secara langsung, atau membangun logika penggabungan ke dalam kode aplikasi kamu. Tidak ada cara bawaan untuk menjaganya tetap DRY. Terakhir, kamu tidak dapat melakukan streaming file TOML. Berbeda dengan JSON Lines, dokumen TOML harus dibaca dan diurai secara keseluruhan sebelum kamu dapat mengakses nilai apa pun. Ini bisa menjadi penting untuk file konfigurasi yang sangat besar, meskipun file konfigurasi sebesar itu seringkali merupakan gejala dari masalah desain yang lebih dalam. Keterbatasan ini tidak membuat TOML pilihan yang buruk untuk tujuan yang dimaksudkan: konfigurasi aplikasi dengan kompleksitas sedang. Mereka hanya mendefinisikan batas-batasnya.
Mengonversi Antara TOML dan Format Lain
Jika kamu memigrasikan proyek dari YAML atau hanya perlu mengonversi data konfigurasi antar format untuk suatu alat, kamu memiliki beberapa pilihan. Untuk mengonversi secara terprogram di Python, kamu dapat menggabungkan pustaka `tomllib` (baca) dan `tomli-w` (tulis) dengan parser YAML seperti `PyYAML`. Membaca file YAML ke dalam dictionary Python dengan `yaml.safe_load()` lalu menuliskannya dengan `tomli_w.dumps()` berfungsi, tetapi paling baik untuk file datar atau bersarang sedang. Struktur bersarang yang sangat dalam, anchor YAML, atau file multi-dokumen akan memerlukan pembersihan manual. Untuk konversi JSON-ke-TOML, pemetaannya jauh lebih bersih karena kedua format memiliki tipe eksplisit. Integer JSON menjadi integer TOML. Boolean JSON menjadi boolean TOML. Pergeseran struktural utama adalah mengubah array objek JSON menjadi array tabel TOML (`[[table]]`), yang dapat ditangani oleh konverter yang baik. Alat daring seperti CocoConvert dapat menangani konversi untuk kamu. Unggah file JSON atau YAML, pilih TOML sebagai format output, dan konverter akan melakukan pekerjaannya. Ini adalah pilihan bagus untuk file konfigurasi yang sederhana. Untuk file dengan fitur khusus YAML seperti anchor atau struktur bersarang yang dalam, kamu masih perlu meninjau hasilnya. CocoConvert akan menandai peringatan konversi ketika menemukan sesuatu yang tidak dapat dipetakan dengan rapi ke TOML, tetapi ia tidak dapat merefaktor struktur data kamu—itu adalah keputusan yang harus kamu buat. Untuk migrasi massal, seperti mengonversi seluruh repositori yang berisi 40 file YAML, mengunggahnya satu per satu bukanlah pilihan. API CocoConvert dibuat untuk ini, memungkinkan kamu mem-batch permintaan dan mengotomatiskan seluruh proses.
Haruskah Kamu Mengubah Proyekmu ke TOML?
Jadi, haruskah kamu beralih? Jawabannya tergantung pada proyek kamu dan apa yang diharapkan oleh toolchain-nya. Untuk proyek Python baru pada tahun 2025, jawabannya adalah ya yang tegas. Gunakan `pyproject.toml`. Ekosistemnya telah distandarisasi untuk itu, dan melawannya hanya akan menciptakan gesekan yang tidak perlu. Jangan jadi orang yang membuat `ruff.toml` terpisah padahal standarnya adalah menggunakan bagian `[tool.ruff]` di file konfigurasi utama proyek. Jika kamu sedang menulis proyek Rust, ini bahkan bukan pertanyaan. Cargo menggunakan TOML, dan itu adalah fitur, bukan bug. Konsistensi format adalah bagian besar mengapa tooling Rust terasa begitu koheren. Untuk proyek yang sudah ada dengan konfigurasi YAML yang berfungsi, saya akan mengatakan migrasi hanya jika YAML itu menjadi sumber masalah. Jika `config.yaml` kamu stabil dan tim memahaminya, biaya beralih—memperbarui dokumen, skrip, dan kebiasaan orang—mungkin tidak sebanding dengan 'kemurnian' penggunaan TOML. Di dunia Kubernetes dan CI/CD (GitHub Actions, GitLab CI, dll.), YAML adalah rajanya. Kamu tidak punya pilihan, dan TOML tidak mencoba menggulingkannya di arena itu. Ujian sebenarnya adalah ini: apakah kamu menulis komentar di file YAML kamu untuk menjelaskan tipe data apa yang *seharusnya* dimiliki oleh suatu nilai? Apakah kamu sedang mengejar bug yang disebabkan oleh angka yang dibaca sebagai string? Itulah sinyal kamu. Kamu sudah melampaui ambiguitas YAML. TOML dirancang untuk menyelesaikan masalah kelas ini dengan membuat tipe eksplisit sejak awal.