Kami Memutuskan untuk Tidak Menunggu Linter yang Sempurna: Migrasi ESLint V9 dan Penerapan Hybrid Biome

Berbagi pengalaman Frontend Chapter Lemonbase yang bermigrasi ke ESLint V9 untuk merespons berakhirnya dukungan ESLint V8, lalu menyelesaikan masalah performa dengan mengadopsi pendekatan hybrid Biome.

Latar belakang

• Pada September 2024 diumumkan berakhirnya dukungan ESLint V8, sehingga migrasi ke V9 menjadi wajib untuk tetap mendapatkan patch keamanan dan perbaikan bug
• Mulai V9, konfigurasi berbasis .eslintrc.js berstatus deprecated, dan Flat Config menjadi default
• Ada sekitar 400 aturan, struktur file konfigurasi yang terbagi dua, dan kebutuhan untuk memeriksa kompatibilitas berbagai plugin

Proses migrasi

• Alat migrasi resmi ESLint ternyata hanya sebatas membungkus dengan @eslint/compat, sehingga hasilnya tidak memenuhi harapan
• Draf sempat dibuat dengan alat AI, tetapi banyak aturan yang terlewat dan muncul berbagai masalah kompatibilitas
• Pada akhirnya, mereka membandingkan aturan V8/V9 satu per satu lewat spreadsheet untuk melakukan pemeriksaan menyeluruh

Masalah performa setelah migrasi

• Setelah naik ke V9, justru waktu eksekusi melambat 30 detik: 154 detik → 184 detik
• Aturan import/no-cycle menjadi 10 kali lebih lambat dibanding V8 dan memakan 45,8% dari total waktu
• Aturan prettier/prettier juga mencapai 10,2%, dengan overhead parsing ganda sebagai bottleneck

Penerapan hybrid Biome

• Alih-alih mengganti sepenuhnya, pendekatannya diubah menjadi “dipakai bersama sambil fokus pada manfaatnya”
• Prettier → Biome Formatter, waktu formatting dipangkas dari 14 detik → 2 detik
• ESLint hanya menangani aturan kustom milik proyek

Hasil akhir

• ESLint V8: 154 detik → ESLint V9: 184 detik
• ESLint Only → hybrid Biome + ESLint: ~20 detik

Pelajaran yang didapat

• Saat menyerahkan migrasi ke AI, sebaiknya minta AI menyusun rencana lebih dulu lalu ditinjau manusia, dan definisikan dengan jelas kriteria keberhasilan (misalnya: hasilnya harus sama dengan V8)
• Daripada menunggu alat yang sempurna, kadang jalan yang lebih cepat adalah merangkai dengan baik alat yang sudah bisa dipakai sekarang

Hal yang perlu diperhatikan

• Jika dua alat dipakai bersama, eslint.config.mjs dan biome.json keduanya harus dikelola, dan ada kemungkinan konflik aturan
• Perlu ditetapkan dengan jelas aturan mana ditangani oleh alat yang mana, serta menjelaskan pembagian peran ini saat onboarding anggota tim baru

[selene]

Sepertinya ini tulisan yang bisa memberi insight bagus bagi mereka yang masih mengalami masalah performa linting.

Kami juga punya pengalaman menurunkan waktu linting yang tadinya memakan lebih dari 200 detik menjadi di bawah 15 detik saat tahun lalu memperbaiki penggunaan hybrid oxc (oxlint) dan ESLint.

Awalnya saya juga nekat melakukan migrasi dengan AI, tetapi karena aturan yang terlewat/berubah terus bermunculan, saya sempat mempertimbangkan untuk meninjaunya satu per satu.
Lalu saya meminta AI menulis skrip untuk mengekstrak aturan yang didukung di oxc, dan memperbaikinya agar hanya aturan yang tidak didukung oxc saja yang diaktifkan di ESLint. Setelah itu, memperbarui aturan yang baru didukung secara berkala pun jadi jauh lebih mudah...

Pada awalnya proses di atas masih semi-otomatis, tetapi sekarang sudah saya definisikan sebagai Skill sehingga cukup dijalankan dengan Claude Code, jadi bebannya juga terasa lebih ringan.

[chamchi]

Apakah Anda tertarik mencoba oxlint dan oxfmt alih-alih eslint dan prettier?
Dengan korespondensi config 1:1, kecepatannya meningkat setidaknya puluhan kali lipat.