Webpack → Vite: bundler माइग्रेशन की कहानी
(engineering.ab180.co)सेवा लॉन्च होने के बाद 5 साल तक इस्तेमाल किए गए Webpack को Vite में ले जाते समय जो अनुभव हुए, उन्हें साझा कर रहा हूँ। कई कमियाँ हो सकती हैं, लेकिन अगर आप इसे दिलचस्पी से पढ़ें तो आभारी रहूँगा।
Webpack के फ़ायदे और web ecosystem में बदलाव
Webpack पिछले 10 सालों से विकसित और maintained होता आया है, और इसका ecosystem अच्छी तरह स्थापित है।
Create React App जैसी कई जगहों पर भी इसका इस्तेमाल होता है, और यह IIFE तरीके से modules को bundle करके कई browsers को support करता है।
लेकिन 5 साल के दौरान सेवा के भीतर features लगभग 3 गुना बढ़ गए, जिससे build time बढ़ा और development experience खराब होने लगा। साथ ही web ecosystem के विकास के साथ ES Module support जैसी कई तरह की बदलौतियाँ भी आईं।
Bundler + Native
हाल के 1~2 सालों में Native की ताकत का इस्तेमाल करके bundling और transpiling करने का चलन उभरने लगा। single-threaded JS की processing limitations को पार करने के लिए कोशिशें होने लगीं।
Golang-आधारित esbuild, Rust-आधारित SWC आदि इसके प्रमुख उदाहरण हैं।
पहला प्रयास: केवल esbuild का उपयोग करके bundling
उस समय stability, plugins और ecosystem को देखते हुए esbuild-आधारित bundler इस्तेमाल करने का फैसला किया गया। साथ ही यह भी देखना था कि esbuild की अपनी performance कितनी है।
package install करने के बाद build script चलाया, तो जो build पहले लगभग 210 सेकंड लेता था, वह सिर्फ 2.16 सेकंड में पूरा हो गया। लगभग 100 गुना तेज build speed मिली।
लेकिन EmotionJS इस्तेमाल करने के लिए Babel लगाने पर यह 10 गुना धीमा हो गया।
और क्योंकि esbuild HMR को support नहीं करता था, इसलिए इसे इस्तेमाल करना मुश्किल लगा। HMR को सीधे implement भी किया जा सकता था, लेकिन लगा कि इसमें बहुत अधिक effort, maintenance और management cost लगेगी।
दूसरा प्रयास: Vite का उपयोग करके bundling
Vite का concept है Dependencies और Source code को अलग करना।
Dependencies install होने के बाद बदलती नहीं हैं, इसलिए उन्हें esbuild से पहले ही transpile किया जाता है। Source code बार-बार बदलता है, इसलिए उसे ESM के रूप में load किया जाता है। build result को cache किया जाता है ताकि development build तेज़ हो सके।
Vite में दिए गए template का उपयोग करके migration आसानी से आगे बढ़ाया गया। कुछ issues थे, लेकिन वे जल्दी हल हो गए, और Webpack की तुलना में कहीं अधिक छोटे और संक्षिप्त configuration लिखे जा सके।
bundler migration का परिणाम
Netlify में build time मापने पर औसतन 250 सेकंड → औसतन 90 सेकंड। पहले के 36% स्तर तक कमी आई।
configuration files सरल होने से team members ने इन्हें इस्तेमाल करके आसानी से custom build environments बनाए, जिससे efficiency बढ़ी।
और बेहतर सुधार के लिए Babel dependency के बिना CSS-in-JS library में बदलाव करना और Monorepo लागू करना संभव है।
ecosystem के संदर्भ में, SWC स्थिर होने पर Babel को replace किया जा सकेगा, और TypeScript Type Checker भी Native में port किया जा रहा है।
सीख
- जो काम बहुत बड़ा दिखता है, उसे छोटे हिस्सों में बाँटकर test किया जाए और खूब चर्चा की जाए, तो वह आसानी से सुलझ जाता है।
- आज जो tools major रूप से इस्तेमाल हो रहे हैं, वे भी ecosystem के विकास के साथ जल्दी गायब हो सकते हैं।
- अच्छी accessibility एक अच्छा environment बनाती है.
3 टिप्पणियां
esbuild की गति कमाल की है।
esbuild की मुख्य वेबसाइट पर भी जब यह 10-100x तेज़ होने की बात करती है, तो मुझे थोड़ा संदेह था, लेकिन इसे असल में देखकर मैं हैरान रह गया!
मैं भी सच में उस दौर का आने का बेसब्री से इंतज़ार कर रहा हूँ! लगता है कि तब development करना वाकई बहुत बेहतर हो जाएगा :)