हमने परफ़ेक्ट linter का इंतज़ार नहीं किया: ESLint V9 migration और Biome hybrid अपनाने का अनुभव

ESLint V8 support समाप्त होने के जवाब में V9 पर migration करने और performance समस्याओं को Biome hybrid अपनाकर हल करने के Lemonbase frontend chapter के अनुभव को साझा किया गया है.

अपनाने की पृष्ठभूमि

• सितंबर 2024 में ESLint V8 support समाप्ति की घोषणा हुई, और security patch व bug fix पाने के लिए V9 migration अनिवार्य हो गया
• V9 से .eslintrc.js आधारित configuration deprecated हो गई और Flat Config डिफ़ॉल्ट बन गया
• लगभग 400 rules, दो-स्तरीय configuration file structure, और विभिन्न plugins की compatibility की जाँच करनी पड़ी

migration प्रक्रिया

• ESLint का official migration tool केवल @eslint/compat से wrap करने के स्तर तक ही मददगार था, इसलिए उम्मीदों पर खरा नहीं उतरा
• AI tool से draft बनाया गया, लेकिन कई missing rules और compatibility समस्याएँ सामने आईं
• अंततः spreadsheet में V8/V9 rules को एक-एक पंक्ति मिलाकर पूरी जाँच की गई

migration के बाद performance समस्या

• V9 पर upgrade करने के बाद उल्टा 154 सेकंड → 184 सेकंड, यानी 30 सेकंड अधिक समय लगा
• import/no-cycle rule, V8 की तुलना में 10 गुना धीमा हो गया और कुल समय का 45.8% लेने लगा
• prettier/prettier rule भी 10.2% पर था, जहाँ double parsing overhead bottleneck बना

Biome hybrid अपनाना

• पूरी तरह replacement करने के बजाय "साथ में इस्तेमाल करते हुए फ़ायदे पर फ़ोकस" करने वाला approach अपनाया गया
• Prettier → Biome Formatter replacement से formatting समय 14 सेकंड → 2 सेकंड हो गया
• ESLint अब केवल project के custom rules संभालता है

अंतिम परिणाम

• ESLint V8: 154 सेकंड → ESLint V9: 184 सेकंड
• ESLint Only → Biome + ESLint hybrid: ~20 सेकंड

सीखी गई बातें

• AI को migration सौंपते समय पहले उससे योजना बनवानी चाहिए, फिर इंसान को review करना चाहिए, और success criteria (जैसे: V8 results से मेल खाना) स्पष्ट रूप से परिभाषित होने चाहिए
• परफ़ेक्ट tool का इंतज़ार करने के बजाय, अभी उपलब्ध tools को सही ढंग से मिलाकर इस्तेमाल करना कभी-कभी ज़्यादा तेज़ रास्ता हो सकता है

ध्यान देने योग्य बातें

• दोनों tools को साथ में इस्तेमाल करने पर eslint.config.mjs और biome.json दोनों को manage करना पड़ता है, और rules के टकराव की संभावना रहती है
• कौन-सा rule किस tool में संभाला जाएगा, यह स्पष्ट रूप से तय होना चाहिए, और नए team members के onboarding के समय इस role split को समझाना ज़रूरी है

[selene]

जो लोग अभी भी lint performance की समस्या झेल रहे हैं, उनके लिए यह लेख काफ़ी उपयोगी insight दे सकता है.

हमने भी पिछले साल oxc(oxlint) और ESLint को hybrid तरीके से इस्तेमाल करने के लिए सुधार करते हुए, 200 सेकंड से ज़्यादा लगने वाले linting समय को 15 सेकंड के भीतर लाने का अनुभव किया है.

मैंने भी शुरुआत में AI की मदद से सीधे migration किया था, लेकिन बार-बार कुछ rules छूट जाते थे या बदल जाते थे, इसलिए सोच रहा था कि क्या उन्हें एक-एक करके review करूँ.
oxc में supported rules निकालने वाली script को AI से लिखवाकर, और केवल वही rules ESLint में enabled रखने की व्यवस्था कर दी जिन्हें oxc support नहीं करता था, तो अब समय-समय पर नए supported rules को update करना भी काफ़ी आसान हो गया है...

शुरुआत में यह प्रक्रिया semi-automated थी, लेकिन अब इसे Skill के रूप में define कर दिया है, इसलिए Claude Code से चलाना भर होता है और इससे बोझ भी काफ़ी कम हो गया, जो अच्छा लगा.

[chamchi]

क्या आप eslint prettier की जगह oxlint और oxfmt इस्तेमाल करने के बारे में सोचेंगे?
config का 1:1 मैपिंग करते हुए भी स्पीड कम से कम कई दर्जन गुना तेज़ हो जाती है