Aku Menolak Nambah Sistem Plugin ke Library Open Source-ku Sendiri, dan Itu Keputusan Terbaik Tahun Ini

Issue nomor 41 di repo library-ku sudah terbuka delapan bulan waktu itu, judulnya "Add plugin system for custom validators". Yang minta bukan orang iseng — seorang maintainer dari proyek lain yang sudah pakai library-ku di production, dengan use case yang masuk akal: dia mau nulis validator custom tanpa harus fork repo-ku. Setiap kali aku buka daftar issue, judul itu selalu ada di urutan atas berdasarkan jumlah reaction, dan setiap kali itu pula aku menutup tab-nya lagi tanpa mengerjakannya.

Library Kecil yang Awalnya Cuma untuk Diriku Sendiri

Library-nya sendiri sederhana: validator environment variable untuk aplikasi Node.js, memastikan DATABASE_URL ada isinya, PORT berupa angka, dan seterusnya, lalu gagal cepat dengan pesan error yang jelas kalau ada yang hilang — daripada aplikasi jalan setengah-setengah dan baru meledak lima menit kemudian di tempat yang tidak terduga. Aku bikin ini awalnya buat proyek sampingan sendiri, iseng kupublikasikan ke npm, dan tidak menyangka orang lain benar-benar mulai memakainya.

API-nya cuma satu fungsi: kasih objek skema, dapat objek environment yang sudah tervalidasi dan bertipe. Tidak ada file konfigurasi, tidak ada plugin, tidak ada opsi tersembunyi. Total kode intinya di bawah 200 baris, nol dependency runtime. Itu yang bikin orang mau coba — mereka bisa baca seluruh sumber kodenya dalam waktu kurang dari lima menit dan langsung paham persis apa yang terjadi di baliknya.

Kenapa Permintaan Plugin Terasa Masuk Akal, dan Kenapa Aku Tetap Menahan Diri

Kalau dipikir dari sisi permintaannya sendiri, sistem plugin itu bukan ide buruk. Beberapa orang butuh validasi custom yang di luar cakupan bawaan — format nomor telepon regional, validasi silang antar dua variable sekaligus, dan semacamnya. Menolak begitu saja terasa seperti mengabaikan kebutuhan nyata dari orang yang sudah setia pakai library ini.

Yang menahanku bukan soal teknis — nambah hook registerValidator() sebenarnya cuma butuh waktu satu sore. Yang menahanku adalah membayangkan versi library ini enam bulan setelah sistem plugin itu ada. Begitu ada satu API ekstensi, permintaan berikutnya selalu datang: opsi konfigurasi plugin, urutan eksekusi plugin, cara plugin saling berkomunikasi, dokumentasi terpisah buat penulis plugin. Aku sudah pernah lihat pola ini di proyek lain tempat aku kerja — library yang tadinya bisa dibaca habis dalam lima menit, perlahan jadi butuh dokumentasi API tersendiri hanya untuk menjelaskan sistem ekstensinya sendiri.

Jadi tiap kali issue itu muncul lagi di notifikasi, aku selalu balas dengan pertanyaan yang sama: "Boleh cerita skema validasi custom yang kamu butuhkan?" Dari situ aku justru bisa lihat apakah kebutuhannya benar-benar butuh sistem plugin, atau sebenarnya cukup diselesaikan dengan fungsi validator biasa yang tinggal dikomposisikan sebelum dan sesudah pemanggilan library-ku — tanpa aku perlu mengubah apa pun di dalam library itu sendiri.

Delapan Bulan Kemudian, Alasan Menahan Diri Itu Terbukti

Minggu lalu ada yang buka pull request kecil ke README, bukan ke kode. Isinya cuma menambahkan satu paragraf di bagian atas: alasan dia memilih library ini dibanding beberapa alternatif lain yang lebih populer adalah karena dia bisa membaca seluruh isi library-nya dalam sekali duduk sebelum menaruhnya di production, sesuatu yang menurutnya makin jarang ditemukan di ekosistem paket JavaScript yang API permukaannya terus membengkak. Dia juga menyebut bahwa timnya sempat mempertimbangkan menulis validator environment variable sendiri dari nol, tapi akhirnya memilih pakai library ini justru karena scope-nya sengaja dibuat sempit, bukan meski scope-nya sempit.

Aku terima PR itu, dan setelahnya iseng buka lagi metrik download mingguan — angkanya naik cukup stabil selama beberapa bulan terakhir, tanpa satu pun rilis fitur besar di antaranya. Satu-satunya perubahan berarti sejak awal tahun cuma perbaikan pesan error dan dukungan TypeScript yang lebih ketat, keduanya memperkuat hal yang sudah ada, bukan menambah permukaan baru.

Issue nomor 41 itu sendiri masih terbuka. Tapi sekarang aku menutupnya dengan komentar berbeda: kubuatkan contoh kecil di dokumentasi yang menunjukkan cara menggabungkan validator custom di luar library, memakai fungsi biasa, tanpa API ekstensi apa pun. Orang yang minta fitur itu delapan bulan lalu akhirnya membalas dengan "oh, ternyata semudah ini" — bukan komplain karena permintaannya ditolak.

Takeaway

Permintaan fitur yang masuk akal secara individual tidak otomatis berarti library-nya harus tumbuh untuk mengakomodasinya — kadang jawaban yang lebih baik adalah menunjukkan cara menyelesaikannya di luar batas API yang sudah ada. Yang membuat orang mempercayakan production mereka ke library kecil bukan daftar fiturnya, tapi kepastian bahwa mereka bisa membaca dan memahami seluruh isinya sendiri. Kalau aku harus menyimpan satu pelajaran dari delapan bulan menahan diri ini, itu adalah: sebelum menambah API baru, coba dulu selesaikan kebutuhannya dengan komposisi di luar library — dan baru pertimbangkan menambah permukaan API kalau cara itu benar-benar tidak cukup.

Sumber gambar: Florian Olivo di Unsplash Sumber gambar: Glenn Carstens-Peters di Unsplash Sumber gambar: Austin Distel di Unsplash