@types/* को dependencies या devDependencies में रखना: मुख्य गलतियाँ

परिचय: @types/* का सवाल अनुभवी डेवलपर्स को भी क्यों परेशान करता है?

क्या आपने कभी किसी त्रुटि को डीबग करने में एक घंटा बिताया है, जो अंततः package.json में @types/* पैकेज के गलत स्थान पर आ गई? यदि हाँ — तो आप अकेले नहीं हैं। प्रश्न «How do I decide whether @types/* goes into dependencies or devDependencies?» ने Stack Overflow पर हज़ारों व्यूज़ एकत्र किए हैं और TypeScript समुदाय के लिए एक वास्तविक सिरदर्द बन गया है।

लगता है, इसमें क्या मुश्किल है? टाइप्स को devDependencies में डाल दिया — और काम खत्म। लेकिन ऐसा नहीं है। जब आपका प्रोजेक्ट बढ़ने लगता है, तीसरे पक्ष की लाइब्रेरीज़, मोनोरेपॉजिटरीज़ और CI/CD पाइपलाइन जुड़ती हैं, तो टाइप्स का गलत स्थान घातक बिल्ड त्रुटियों, प्रोडक्शन में अप्रत्याशित क्रैश या इससे भी बदतर, टाइपिंग के मौन नुकसान का कारण बन सकता है।

इस लेख में, हम @types/* के साथ काम करते समय शीर्ष 5 सबसे सामान्य गलतियों पर चर्चा करेंगे, वास्तविक परिदृश्यों के आधार पर सही निर्णय लेना सीखेंगे और एक चेक-लिस्ट बनाएंगे जो आपको समस्याओं से बचाएगी। तैयार हैं? चलिए शुरू करते हैं!

गलती #1: «सभी @types/* हमेशा devDependencies में» — एक मिथक जो बिल्ड को तोड़ता है

इंटरनेट पर सबसे लोकप्रिय सलाह यह है: «टाइप्स runtime कोड नहीं हैं, इसलिए उन्हें हमेशा devDependencies में होना चाहिए»। और यह 90% मामलों में वास्तव में सही है। लेकिन एक महत्वपूर्ण अपवाद है जिसे भुला दिया जाता है।

कब devDependencies सही विकल्प है

यदि आप एक एप्लिकेशन लिख रहे हैं (Express पर वेब सर्वर, React फ्रंटएंड, कमांड-लाइन उपयोगिता), तो सभी @types/* को बेझिझक devDependencies में भेजें। आपका अंतिम उपयोगकर्ता TypeScript को कंपाइल नहीं करता — वह पहले से कंपाइल किए गए JavaScript को चलाता है। टाइप्स की आवश्यकता केवल आपको डेवलपमेंट के दौरान होती है।

// Express पर एप्लिकेशन के लिए उदाहरण\n{\n  "devDependencies": {\n    "@types/express": "^4.17.21",\n    "@types/node": "^20.11.0",\n    "typescript": "^5.3.3"\n  }\n}

कब devDependencies एक घातक गलती है

अब कल्पना करें: आप एक लाइब्रेरी विकसित कर रहे हैं जो बाहरी उपभोक्ताओं के लिए TypeScript टाइप्स निर्यात करती है। यदि आपकी लाइब्रेरी के टाइप्स @types/express पर निर्भर हैं, और आपने इसे devDependencies में रखा है, तो आपकी लाइब्रेरी स्थापित करने वाले उपयोगकर्ता को ये टाइप्स स्वचालित रूप से प्राप्त नहीं होंगे। और उसका IDE लाल रेखांकन दिखाना शुरू कर देगा।

// ❌ टाइप्स निर्यात करने वाली लाइब्रेरी के लिए गलत\n{\n  "devDependencies": {\n    "@types/express": "^4.17.21" // उपयोगकर्ता ये टाइप्स नहीं देख पाएगा!\n  }\n}\n\n// ✅ सही\n{\n  "dependencies": {\n    "@types/express": "^4.17.21" // टाइप्स उपभोक्ताओं के लिए उपलब्ध होंगे\n  }\n}

सुनहरा नियम: यदि आपकी लाइब्रेरी @types/* पैकेज से टाइप्स को पुनः निर्यात करती है या उन्हें सार्वजनिक API में उपयोग करती है, तो वह पैकेज dependencies में होना चाहिए। यदि टाइप्स केवल आंतरिक रूप से उपयोग किए जाते हैं — devDependencies।

गलती #2: «कोड में उपयोग कर रहा हूँ» और «टाइप्स में उपयोग कर रहा हूँ» के बीच अंतर को अनदेखा करना

कई डेवलपर्स भ्रमित होते हैं: «मैं express से Request इम्पोर्ट कर रहा हूँ, इसलिए express को dependencies में होना चाहिए»। यह express पैकेज के लिए सही है, लेकिन इसके टाइप्स के लिए नहीं।

आइए एक विशिष्ट उदाहरण के साथ समझते हैं। @types/lodash पैकेज के उपयोग के तीन परिदृश्य हैं:

\n
• परिदृश्य A: आप import _ from 'lodash' लिखते हैं और _.chunk() का उपयोग करते हैं। टाइप्स की आवश्यकता केवल कंपाइलेशन के लिए है — devDependencies।
\n
• परिदृश्य B: आप एक फंक्शन function mySort(arr: T[]): T[] बनाते हैं और अंदर _.orderBy का उपयोग करते हैं। टाइप्स बाहर नहीं जाते — devDependencies।
\n
• परिदृश्य C: आप export function proc लिखते हैं
\n