अब से सिर्फ़ ESM.

पहले तक मैं सभी JavaScript लाइब्रेरीज़ को तेज़ी से ESM में बदलने के तरीके को लेकर नकारात्मक था। लेकिन अब ESM से जुड़ी तकनीकें और उसका महत्व लगातार बढ़ रहे हैं, इसलिए मैं चाहता हूँ कि सभी डेवलपर्स ज़रूर ESM पर आएँ। इसके कारण ये हैं।

कारण

• तैयार टूल्स
  • Vite, ESLint, tsx जैसे कई टूल आ चुके हैं जो ESM में जाने में मदद कर सकते हैं।
  • पुरानी लाइब्रेरी शैली (CJS) के लिए आधुनिक शैली ESM पर निर्भर होना आसान नहीं है, इसलिए भविष्य के विकास के लिए आगे बढ़ना ज़रूरी है।
  • नए Node.js में ESM लाइब्रेरी को require() फ़ंक्शन से लोड करने का तरीका विकसित किया गया है, जिससे ESM अपनाना और आसान हो गया है।
• डुअल सपोर्ट की समस्या
  • दोनों तरीकों की डिज़ाइन में बड़ा अंतर है, इसलिए interoperability काफ़ी कम हो जाती है।
  • यूज़र को अलग-अलग जाकर यह जाँचना पड़ता है कि ESM सपोर्ट है या नहीं।
  • दोनों तरीकों को सपोर्ट करना पड़ने से पैकेज का आकार बहुत बड़ा हो जाता है।

कब बदलें?

• नए पैकेज को बिना किसी अपवाद के ESM में ले जाएँ।
• ब्राउज़र-टार्गेटेड लाइब्रेरी के मामले में इससे हल्का bundle बनाया जा सकता है।
• CLI प्रोग्राम में भी इसका उपयोग करने वाले लोग स्वाभाविक रूप से ESM की ओर आ सकते हैं।
• लेकिन उससे पहले, जिन लाइब्रेरीज़ पर पहले से निर्भरता है उनकी स्थिति और यूज़र्स की आवश्यकताओं को समझना महत्वपूर्ण है।

कितना बदलना चाहिए?

लाइब्रेरी की dependencies समझने के लिए मैंने dependency analyzer बनाया है। इससे आप निर्भर लाइब्रेरीज़ की स्थिति और ESM में बदलने पर पड़ने वाले असर तक देख सकते हैं।

आगे क्या करना है

मैं जिन पैकेजों का रखरखाव करता हूँ, उन्हें धीरे-धीरे ESM में बदलने और उनकी dependencies को विस्तार से देखने की योजना बना रहा हूँ। साथ ही, node-modules-inspector का उपयोग करके कई दिलचस्प ideas भी तैयार कर रहा हूँ, ताकि और उपयोगी insights मिलें और आगे भी बेहतर तरीक़े खोजने में मदद मिले।

मैं एक हल्के, ज़्यादा लचीले और optimized JavaScript/TypeScript ecosystem की उम्मीद कर रहा हूँ। आशा है यह मददगार रहा होगा।