Iseng menyambangi beberapa repo pribadi. Akhirnya saya kembali membuka salah satu library NPM yang pernah saya publish 3 tahun silam (tahun 2022), yaitu dom-screenshot.
Library ini merupakan fork & modification dari sebuah library yang lebih tua, yaitu dom-to-image dimana fungsinya untuk mengubah elemen DOM menjadi gambar (SVG, PNG, JPEG).
Spoiler (Kenapa saya membuat library ini?)
Pada suatu ketika, perusahaan tempat saya bekerja ingin mengimplementasikan sebuah fitur screenshot untuk halaman tertentu menggunakan React. Tapi beberapa library yang kita temukan, ternyata kurang cocok dengan spesifikasi. Hingga akhirnya kita menemukan dom-to-image yang memang masih pure javascript, namun waktu itu menggunakan build process hingga bundle yang agak usang.
Dari dom-to-image saya dan teman-teman kemudian berinisiatif melakukan fork dan modifikasi agar lebih seamless saat integrasi dengan ReactJS. Akhirnya jadilah @mkhuda/dom-screenshot, yang benar-benar pure fork + full rework, tapi dengan Typescript.
Kali ini, saya memutuskan melakukan perombakan total library saya sendiri, dom-screenshot, ditemani Claude Code (menggunakan model Haiku 4.5, agar lebih irit) sebagai mitra vibe coding. Berikut adalah langkah-langkah yang saya lakukan:
1, Analisis Awal
Langkah pertama tentu kita bedah isi package.json dan melihat langsung sumber kode.
Yang terlihat adalah Rollup masih di versi 2.x, TypeScript tertinggal di 4.x, dan beberapa dependensi sudah deprecated sejak zaman pandemi pertama. Wkwkwk
Saya lalu meminta Claude Code untuk menganalisis semuanya, menyusun daftar pembaruan prioritas lengkap dengan potensi dampaknya terhadap API lama. Dengan begitu, saya punya mapping yang jelas sebelum mulai menyentuh satu baris kode pun. (Lihat screenshot analisis dari Claude diatas)
2, Migrasi ke TypeScript
Setelah tahu bagian mana saja yang perlu dibenahi, saya langsung beralih ke big step, yakni migrasi penuh ke TypeScript.
Secara logika, jika ingin kita kerjakan sendiri sepertinya terlihat mudah, cukup ubah ekstensi
.jsjadi.ts, ubah beberapa jsdom ke typescript dll. Tapi, ternyata tidak semudah itu, Ferguso!
Kelihatannya cukup simpel:
Di titik ini, Claude Code benar-benar menunjukkan kegunaannya. Ia membantu saya memahami pola dependensi di dalam proyek dan menyarankan solusi lewat lazy initialization pattern, tanpa saya perlu menjelaskan konteks panjang lebar.
3, Upgrade Build Tool
Sebenarnya sebelum migrasi ke Typescript, Claude Code melakukan upgrade build tools (rollup dan antek-anteknya) sekaligus menyesuaikan beberapa dependency tooling agar lebih modern dan kompatibel dengan sistem yang lebih gress.
Setelah beberapa iterasi (dan secangkir kopi ekstra ☕️), akhirnya build berhasil dengan dual output: format ESM sekitar 26 KB dan IIFE ter-minify hanya 9,6 KB. Semuanya sudah mendukung tree-shaking dan source map yang bersih.
Yang menarik, proses build kini terasa cepat dan ringan, tidak ada lagi drama dependensi misterius atau bundling yang macet di tengah jalan. Peralihan ke tooling modern ini membuat seluruh pipeline terasa modern.
4, Jest versus Vitest. Pilih mana?
Awalnya niatnya cuma “asal ada test,” tapi entah kenapa akhirnya Claude Code malah menulis test cases satu ekosistem lengkap.
Claude menulis 33 test mencakup hampir semua fungsi utama, menambahkan custom matcher, serta membuat mock utility untuk Canvas dan Image API agar simulasi berjalan mulus di jsdom. Claude Code benar-benar banyak menghabiskan billing dibagian ini. 😂 😂
Dibagian ini pun saya diberi tahu tentang perbandingan antara penggunaan Jest dengan Vitest. Benar-benar bagian yang paling asyik sekaligus memakan banyak dana pokoknya! Wkwkwk
Lihat screenshot diatas (jawaban dari Claude Code), praktis Vitest adalah terbaik untuk kasus library dom-screenshot ini.
5, Contoh React & Dokumentasi
Setelah semuanya stabil, dan penuh drama. Saya berniat ingin memastikan library ini tidak hanya bekerja di teori, tapi juga di real world case.
Maka saya meminta bantuan Claude Code untuk membuat contoh use case dengan React 18, bukan sekadar demo “Hello World,” tapi benar-benar simulasi penggunaan library di proyek produksi.
Claude Code membuatnya dengan tidak sembarangan, meskipun examples ini terlihat simple, tapi benar-benar works like a charm! Hampir sempurna untuk sebuah contoh kecil implementasi dom-screenshot.
Berapa cost totalnya?
Meskipun library dom-screenshot ini bukan kategori library kompleks. Tapi ternyata cost atau billing yang tersedot dari Vibe Coding sesi kali ini cukup mencengangkan, kurang lebih 4,5 USD dengan total kurang lebih 18 juta token.
Kenapa bisa agak mahal? Karna Vibe Coding ini adalah total revamp + penambahan test cases yang sangat kompleks + adanya example world case scenario. Jadi Claude Code benar-benar saya buat full gass + ngebul pada sesi ini.
Total Biaya/Cost: +- 4USD
Total Estimasi Token: 18,5 juta token
Model: Claude Haiku 4.5
Waktu eksekusi: +- 3 jam
Menurut kalian dengan total 18 juta token seperti diatas, adakah platform Vibe Coding lain yang lebih murah?
OpenCode?
Gemini CLI?
Cline?
Cursor?
Github Copilot?
Lesson Learned
Refactor kali ini memberi banyak sekali pelajaran. Awalnya saya hanya berniat memperbarui dependensi dan menambal bagian yang sudah usang, tetapi ternyata proses Vibe Coding ini berkembang biak menjadi perjalanan penuh pembelajaran, baik tentang arsitektur, konsistensi, dan kerja sama antara manusia dan AI. Cieeh..
Dengan bantuan Claude Code, saya bisa memahami ulang struktur proyek lama dan membangunnya kembali dengan fondasi yang lebih kuat: type safety yang jelas, sistem build modern, dan pengujian yang menyeluruh.
Meski agak mahal sih! Tapi tetap worth it menurut saya. 😬
Happy Vibe Coding, guys!
Tinggalkan Balasan