TypeScript 7 का नया Go-आधारित कंपाइलर, tsgo, पहले से ही ESLint, ts-jest और ts-morph जैसे लोकप्रिय डेवलपमेंट टूल्स को खराब कर रहा है। यह समस्या तब तक बनी रहेगी जब तक कि आगामी 7.1 रिलीज़ में कंपाइलर का प्रोग्रामैटिक API स्थिर (stabilize) नहीं हो जाता, जिसका अर्थ है कि जो टीमें इन टूल्स पर निर्भर हैं, उन्हें अपनी अपग्रेड योजनाओं को रोक देना चाहिए।

TypeScript 7 में क्या बदला

इस रिलीज़ में tsgo पेश किया गया है, जो टाइप-चेकर का एक Go पोर्ट है जिसे TypeScript टीम ने Project Corsa कोडनेम दिया है। कोर को JavaScript से Go में ले जाने से कंपाइलर 10 गुना तक तेज़ बिल्ड दे सकता है, यह एक ऐसी हेडलाइन है जिसने CI पाइपलाइनों में लगने वाले मिनटों को कम करने की चाह रखने वाले शुरुआती उपयोगकर्ताओं (early adopters) को आकर्षित किया है।

टूल्स क्यों विफल हो रहे हैं

TypeScript के साथ काम करने वाले टूल्स सीधे टाइप-चेकर से बात नहीं करते हैं। वे आंतरिक APIs के एक सेट को कॉल करते हैं जो टाइप जानकारी, डायग्नोस्टिक्स और AST ट्रैवर्सल (traversal) को एक्सपोज़ करते हैं। उन APIs को tsgo के लिए फिर से लिखा गया है और वे वर्शन 7.1 तक परिवर्तनशील (in flux) रहेंगे। इसका परिणाम क्रैश और साइलेंट फेलियर की एक श्रृंखला है:

  • typescript-eslint – npm इसे TypeScript 7 के साथ इंस्टॉल करने से मना कर देता है; ज़बरदस्ती इंस्टॉल करने पर ESLint TypeError देता है।
  • ts-jest – उन आंतरिक मेथड्स को कॉल करने की कोशिश करता है जो Go वर्शन में अब मौजूद नहीं हैं, जिससे टेस्ट-फ़ाइल ट्रांसफ़ॉर्मेशन बीच में ही रुक जाता है।
  • ts-morph – कोड स्ट्रक्चर को समझने के लिए स्टेबल API की अपेक्षा करता है; वर्तमान API के साथ यह गलत परिणाम दे सकता है या बिना किसी चेतावनी के विफल हो सकता है।
  • Monorepos – tsgo कुछ जेनेरिक टाइप पैरामीटर्स को हटा देता है, जिससे ऐसे टाइप एरर आते हैं जो केवल बड़े, मल्टी-पैकेज प्रोजेक्ट्स में ही दिखाई देते हैं।

कोई भी वर्कफ़्लो जो TypeScript 7 के साथ लिंटिंग, Jest टेस्टिंग या कोड-एनालिसिस को मिलाता है, उसमें संभवतः 'red builds' (फेल बिल्ड) देखने को मिलेंगे।

कौन प्रभावित है

  • फ्रंट-एंड टीमें जो हर पुल रिक्वेस्ट (pull request) के हिस्से के रूप में ESLint चलाती हैं।
  • बैक-एंड सर्विसेज जो यूनिट टेस्टिंग के लिए ts-jest पर निर्भर हैं।
  • लाइब्रेरीज़ जो कोड जनरेशन या डॉक्यूमेंटेशन के लिए ts-morph का उपयोग करती हैं।
  • वे संगठन जिनमें मोनोरेपो (monorepo) सेटअप है जहाँ टाइप इन्फरेंस (type inference) पहले से ही जटिल है।

यदि TypeScript अपग्रेड के बाद आपकी CI पाइपलाइन 'red' हो गई है, तो इसका कारण संभवतः ऊपर दिए गए कारणों में से एक है।

7.1 तक एक सुरक्षित माइग्रेशन पथ

टूल्स को खराब किए बिना स्पीड का लाभ बनाए रखने का सबसे सरल तरीका तेज़ टाइप-चेकिंग स्टेप को वास्तविक बिल्ड से अलग (decouple) करना है:

  1. मुख्य TypeScript वर्शन को 6.x पर पिन करें – यह उस स्टेबल API को बनाए रखता है जिसकी सभी टूल्स अपेक्षा करते हैं।
  2. @typescript/native-preview को एक dev dependency के रूप में जोड़ें – यह पैकेज CI में त्वरित टाइप-चेकिंग के लिए tsgo बाइनरी प्रदान करता है।
  3. तेज़ चेक्स के लिए --noEmit के साथ tsgo चलाएं – यह टाइप को वैलिडेट करता है लेकिन आउटपुट फ़ाइलें नहीं बनाता है।
  4. वास्तविक बिल्ड के लिए क्लासिक tsc कंपाइलर का उपयोग करें – tsc अभी भी JavaScript बनाता है और 6.x API का पालन करता है।
npm install -D typescript@^6.9
npm install -D @typescript/native-preview

अपने package.json स्क्रिप्ट्स को अपडेट करें:

{
  "scripts": {
    "typecheck:fast": "tsgo --noEmit",
    "build": "tsc"
  }
}

इस डुअल सेटअप के साथ, आप ESLint, ts-jest और ts-morph के साथ कम्पैटिबिलिटी बनाए रखते हुए CI में दस गुना स्पीड बूस्ट प्राप्त कर सकते हैं।

आप सीधे 7.0 पर कब अपग्रेड कर सकते हैं

यदि आपका कोडबेस केवल tsc को कॉल करता है—कोई लिंटिंग नहीं, कोई Jest नहीं, कोई ts-morph नहीं—तो अस्थिर API आपको प्रभावित नहीं करेगी। उस सीमित स्थिति में, आप तुरंत TypeScript 7 पर जा सकते हैं और बिना किसी अतिरिक्त कदम के परफॉरमेंस में सुधार का आनंद ले सकते हैं।

किन बातों का ध्यान रखें

  • वर्शन 7.1 – TypeScript टीम ने संकेत दिया है कि इस रिलीज़ में प्रोग्रामैटिक API को फ्रीज़ (freeze) कर दिया जाएगा। एक बार जब यह आ जाएगा, तो tsgo और मौजूदा टूलिंग के बीच का अंतर समाप्त हो जाएगा, जिससे एक क्लीन अपग्रेड संभव हो सकेगा।
  • टूलिंग अपडेट्स – typescript-eslint, ts-jest और ts-morph के नए रिलीज़ पर नज़र रखें। 7.1 के आने के तुरंत बाद वे कम्पैटिबल वर्शन जारी करेंगे।
  • CI कॉन्फ़िगरेशन – याद रखें कि एक बार API स्थिर हो जाने के बाद tsgo --noEmit को नियमित tsc कॉल से बदल दें; प्रीव्यू पैकेज की अब आवश्यकता नहीं होगी।

निष्कर्ष (Takeaway): जब तक 7.1 API लॉक-इन नहीं हो जाता, तब तक अपने मुख्य कंपाइलर के लिए TypeScript 6.x पर ही रहें, तेज़ चेक्स के लिए @typescript/native-preview जोड़ें, और बिल्ड के लिए tsc का उपयोग जारी रखें। इससे लिंटिंग और टेस्टिंग खराब होने से बचती है और साथ ही नए Go इंजन के परफॉरमेंस लाभ भी मिलते रहते हैं।