Sebuah analisis teknis terbaru yang menyoroti berbagai jebakan parsing YAML telah memicu kembali diskusi tentang format file konfigurasi di komunitas developer. Meskipun YAML dirancang untuk lebih ramah bagi manusia dibandingkan JSON , kompleksitasnya telah menciptakan perilaku tak terduga yang mengejutkan bahkan developer berpengalaman sekalipun.
Paradoks Kesederhanaan
Isu utama berasal dari tujuan ambisius YAML untuk dapat dibaca manusia sambil mempertahankan kemampuan parsing mesin. Tidak seperti JSON yang hanya menggunakan enam diagram railroad dalam spesifikasinya, YAML memerlukan 10 bab dengan penomoran bagian empat tingkat dan halaman errata khusus. Kompleksitas ini termanifestasi dalam beberapa cara bermasalah yang sering dihadapi developer.
Masalah Norway menggambarkan isu-isu ini dengan sempurna. Kode negara seperti NO ( Norway ) secara otomatis dikonversi menjadi nilai boolean false, menciptakan kegagalan tersembunyi dalam file konfigurasi. Demikian pula, nilai seperti on, off, yes, dan no diinterpretasikan sebagai boolean daripada string, menyebabkan perilaku tak terduga ketika kata-kata umum ini muncul dalam data konfigurasi.
Ringkasan Masalah Parsing YAML:
- Masalah Norway: Kode negara seperti "NO" dikonversi menjadi boolean
false - Konversi Boolean: "on", "off", "yes", "no" secara otomatis menjadi boolean
- Angka Sexagesimal: "22:22" diparsing sebagai ekspresi matematika (1342) alih-alih string
- String Tanpa Tanda Kutip: Konversi tipe otomatis menciptakan perilaku yang tidak terduga
- Spesifikasi Kompleks: 10 bab dengan bagian berlevel 4 versus 6 diagram railroad milik JSON
Angka Sexagesimal dan Kejutan Lainnya
Salah satu fitur paling aneh dari YAML adalah dukungannya untuk angka sexagesimal (basis-60). Nilai mirip timestamp seperti 22:22 diparsing sebagai ekspresi matematika daripada string, menghasilkan angka desimal 1342. Fitur ini, yang mungkin ditambahkan untuk mendukung nilai waktu, menciptakan kebingungan dalam konteks di mana parsing semacam itu tidak diharapkan.
Komunitas telah mengidentifikasi jebakan parsing tambahan termasuk konversi tipe otomatis string tanpa tanda kutip, sistem anchor dan alias yang kompleks, serta dukungan untuk kunci non-string yang dapat rusak dengan cara yang halus.
Solusi Komunitas dan Workaround
Developer telah mengembangkan berbagai strategi untuk mengurangi masalah YAML . Pendekatan paling umum melibatkan pemberian tanda kutip pada semua nilai string, yang menghilangkan sebagian besar masalah konversi tipe otomatis. Tools seperti yamllint dapat menangkap banyak masalah selama pengembangan, meskipun ini menambah kompleksitas pada apa yang seharusnya menjadi format konfigurasi sederhana.
Hampir semua ini diselesaikan pada dasarnya dengan memberikan tanda kutip di sekitar string. YAML memiliki kasus penggunaan di mana Anda menginginkan hal-hal yang tidak dilakukan JSON seperti rekursi atau anchor/alias/tag.
Beberapa tim telah mengadopsi StrictYAML , subset yang menghilangkan fitur bermasalah dengan hanya mendukung string, list, dan dictionary. Yang lain menghasilkan JSON dari bahasa yang lebih cocok daripada menulis YAML secara manual, yang memberikan abstraksi dan kemampuan reuse yang lebih baik.
Strategi Mitigasi YAML:
- Kutip Semua String: Menghilangkan sebagian besar masalah konversi tipe otomatis
- Gunakan yamllint: Menangkap masalah umum selama pengembangan
- Hindari Kunci Bermasalah: Jangan gunakan "on", "off", "yes", "no" sebagai kunci tanpa tanda kutip
- Generate JSON: Gunakan bahasa pemrograman untuk menghasilkan JSON daripada menulis YAML secara manual
- Adopsi StrictYAML: Gunakan subset yang menghilangkan fitur-fitur bermasalah
Pencarian Alternatif yang Lebih Baik
Diskusi telah menyoroti beberapa format konfigurasi alternatif yang mendapat perhatian. TOML menawarkan kesederhanaan tanpa jebakan YAML tetapi kurang ekspresif untuk konfigurasi kompleks. HashiCorp Configuration Language ( HCL ) menyediakan kemampuan validasi yang meningkatkan kepercayaan dalam setup yang lebih besar. Opsi yang lebih eksperimental seperti CUE , Dhall , dan KDL mencoba mengatasi kekurangan YAML dengan pendekatan berbeda untuk manajemen konfigurasi.
JSON5 dan JSONC ( JSON with comments) telah muncul sebagai solusi jalan tengah, menambahkan dukungan komentar yang membuat YAML menarik sambil mempertahankan perilaku parsing JSON yang dapat diprediksi. Namun, format-format ini kurang memiliki adopsi luas yang membuat YAML ada di mana-mana dalam workflow pengembangan modern.
Format Konfigurasi Alternatif:
- TOML: Format sederhana tanpa jebakan YAML , ekspresivitas terbatas
- HCL (HashiCorp): Kemampuan validasi, bagus untuk infrastructure as code
- JSON5/JSONC: JSON dengan komentar dan trailing comma
- StrictYAML: Subset YAML hanya dengan string, list, dan dictionary
- CUE/Dhall/KDL: Format eksperimental yang mengatasi kekurangan YAML
- Jsonnet: Bahasa templating yang menghasilkan JSON
Masalah Persistensi
Meskipun masalah-masalahnya terdokumentasi dengan baik, YAML tetap tertanam dalam dalam tools populer seperti Kubernetes , Ansible , dan sistem CI/CD yang tak terhitung jumlahnya. Ini menciptakan efek jaringan di mana developer harus bekerja dengan YAML terlepas dari preferensi mereka. Daya tarik visual format melalui struktur berbasis indentasi terus menarik pengguna, bahkan saat mereka menghadapi kompleksitas parsing-nya.
Perdebatan ini mencerminkan tantangan yang lebih luas dalam pengembangan perangkat lunak: menyeimbangkan keterbacaan manusia dengan kemampuan parsing mesin. Sementara YAML berhasil menciptakan format yang terlihat bersih dan dapat dibaca, kompleksitas tersembunyinya sering merusak keuntungan produktivitas yang dimaksudkan untuk diberikan.
Saat komunitas terus mengeksplorasi alternatif, konsensusnya tampaknya adalah kesadaran daripada pengabaian. Memahami jebakan YAML , menggunakan tooling yang tepat, dan mengetahui kapan memilih alternatif tampaknya menjadi jalan pragmatis ke depan bagi sebagian besar tim pengembangan.
Referensi: The yaml document from hell