टाइपस्क्रिप्ट की शक्ति को उजागर करना: tsconfig में मुख्य बातें

यदि आप जटिल वेब एप्लिकेशन बना रहे हैं, तो संभवतः टाइपस्क्रिप्ट आपकी पसंद की प्रोग्रामिंग भाषा है। टाइपस्क्रिप्ट को इसकी मजबूत प्रकार प्रणाली और स्थैतिक विश्लेषण क्षमताओं के लिए बहुत पसंद किया जाता है, जो इसे यह सुनिश्चित करने के लिए एक शक्तिशाली उपकरण बनाता है कि आपका कोड मजबूत और त्रुटि मुक्त है।

यह कोड संपादकों के साथ एकीकरण के माध्यम से विकास प्रक्रिया को भी तेज करता है, जिससे डेवलपर्स को कोड को अधिक कुशलता से नेविगेट करने और अधिक सटीक संकेत और स्वत: पूर्णता प्राप्त करने की अनुमति मिलती है, साथ ही बड़ी मात्रा में कोड की सुरक्षित रीफैक्टरिंग सक्षम होती है।

कंपाइलर टाइपस्क्रिप्ट का दिल है, जो टाइप की शुद्धता की जांच करने और टाइपस्क्रिप्ट कोड को जावास्क्रिप्ट में बदलने के लिए जिम्मेदार है। हालाँकि, टाइपस्क्रिप्ट की शक्ति का पूरी तरह से उपयोग करने के लिए, कंपाइलर को सही ढंग से कॉन्फ़िगर करना महत्वपूर्ण है।

प्रत्येक टाइपस्क्रिप्ट प्रोजेक्ट में एक या अधिक tsconfig.json फ़ाइलें होती हैं जिनमें कंपाइलर के लिए सभी कॉन्फ़िगरेशन विकल्प होते हैं।

आपके टाइपस्क्रिप्ट प्रोजेक्ट्स में इष्टतम प्रकार की सुरक्षा और डेवलपर अनुभव प्राप्त करने के लिए tsconfig को कॉन्फ़िगर करना एक महत्वपूर्ण कदम है। इसमें शामिल सभी प्रमुख कारकों पर सावधानीपूर्वक विचार करने के लिए समय निकालकर, आप विकास प्रक्रिया को तेज कर सकते हैं और यह सुनिश्चित कर सकते हैं कि आपका कोड मजबूत और त्रुटि मुक्त है।

मानक कॉन्फ़िगरेशन के नुकसान

Tsconfig में डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण डेवलपर्स टाइपस्क्रिप्ट के अधिकांश लाभों से वंचित हो सकते हैं। ऐसा इसलिए है क्योंकि यह कई शक्तिशाली टाइप-चेकिंग क्षमताओं को सक्षम नहीं करता है। "डिफ़ॉल्ट" कॉन्फ़िगरेशन से मेरा मतलब एक कॉन्फ़िगरेशन से है जहां कोई टाइप-चेकिंग कंपाइलर विकल्प सेट नहीं हैं।

उदाहरण के लिए:

 { "compilerOptions": { "target": "esnext", "module": "esnext", "esModuleInterop": true, "forceConsistentCasingInFileNames": true, "skipLibCheck": true, }, "include": ["src"] }

कई प्रमुख कॉन्फ़िगरेशन विकल्पों की अनुपस्थिति के परिणामस्वरूप दो प्राथमिक कारणों से कोड की गुणवत्ता कम हो सकती है। सबसे पहले, टाइपस्क्रिप्ट का कंपाइलर विभिन्न मामलों में null और undefined प्रकारों को गलत तरीके से संभाल सकता है।

दूसरे, any प्रकार आपके कोडबेस में अनियंत्रित रूप से प्रकट हो सकता है, जिससे इस प्रकार के आसपास अक्षम प्रकार की जाँच हो सकती है।

सौभाग्य से, कॉन्फ़िगरेशन में कुछ विकल्पों में बदलाव करके इन समस्याओं को ठीक करना आसान है।

सख्त मोड

 { "compilerOptions": { "strict": true } }

स्ट्रिक्ट मोड एक आवश्यक कॉन्फ़िगरेशन विकल्प है जो टाइप-चेकिंग व्यवहारों की एक विस्तृत श्रृंखला को सक्षम करके प्रोग्राम की शुद्धता की मजबूत गारंटी प्रदान करता है।

Tsconfig फ़ाइल में सख्त मोड को सक्षम करना अधिकतम प्रकार की सुरक्षा और बेहतर डेवलपर अनुभव प्राप्त करने की दिशा में एक महत्वपूर्ण कदम है।

tsconfig को कॉन्फ़िगर करने में थोड़े अतिरिक्त प्रयास की आवश्यकता होती है, लेकिन यह आपके प्रोजेक्ट की गुणवत्ता में सुधार करने में काफी मदद कर सकता है।

strict कंपाइलर विकल्प सभी सख्त मोड परिवार विकल्पों को सक्षम करता है, जिसमें noImplicitAny , strictNullChecks , strictFunctionTypes , अन्य शामिल हैं।

इन विकल्पों को अलग से भी कॉन्फ़िगर किया जा सकता है, लेकिन इनमें से किसी को भी बंद करने की अनुशंसा नहीं की जाती है। आइये यह देखने के लिए उदाहरण देखें कि ऐसा क्यों है।

किसी भी अनुमान को निहित करें

 { "compilerOptions": { "noImplicitAny": true } }

any प्रकार स्थैतिक प्रकार प्रणाली में एक खतरनाक खामी है, और इसका उपयोग सभी प्रकार-जाँच नियमों को अक्षम कर देता है। परिणामस्वरूप, टाइपस्क्रिप्ट के सभी लाभ खो जाते हैं: बग छूट जाते हैं, कोड संपादक संकेत ठीक से काम करना बंद कर देते हैं, इत्यादि।

any उपयोग केवल चरम मामलों में या प्रोटोटाइप आवश्यकताओं के लिए ठीक है। हमारे सर्वोत्तम प्रयासों के बावजूद, कभी-कभी any प्रकार गुप्त रूप से कोडबेस में घुस सकता है।

डिफ़ॉल्ट रूप से, कंपाइलर कोडबेस में any की उपस्थिति के बदले में हमें बहुत सी त्रुटियों को माफ कर देता है। विशेष रूप से, टाइपस्क्रिप्ट हमें चर के प्रकार को निर्दिष्ट नहीं करने की अनुमति देता है, तब भी जब प्रकार का स्वचालित रूप से अनुमान नहीं लगाया जा सकता है।

समस्या यह है कि हम गलती से एक चर के प्रकार को निर्दिष्ट करना भूल सकते हैं, उदाहरण के लिए, एक फ़ंक्शन तर्क के लिए। any त्रुटि दिखाने के बजाय, टाइपस्क्रिप्ट स्वचालित रूप से वेरिएबल के प्रकार का अनुमान लगाएगा।

 function parse(str) { // ^? any return str.split(''); } // TypeError: str.split is not a function const res1 = parse(42); const res2 = parse('hello'); // ^? any

noImplicitAny कंपाइलर विकल्प को सक्षम करने से कंपाइलर उन सभी स्थानों को हाइलाइट कर देगा जहां एक वेरिएबल का प्रकार स्वचालित रूप से any के रूप में अनुमानित होता है। हमारे उदाहरण में, टाइपस्क्रिप्ट हमें फ़ंक्शन तर्क के प्रकार को निर्दिष्ट करने के लिए प्रेरित करेगा।

 function parse(str) { // ^ Error: Parameter 'str' implicitly has an 'any' type. return str.split(''); }

जब हम प्रकार निर्दिष्ट करते हैं, तो टाइपस्क्रिप्ट किसी संख्या को स्ट्रिंग पैरामीटर में पास करने की त्रुटि को तुरंत पकड़ लेगा। वेरिएबल res2 में संग्रहीत फ़ंक्शन का रिटर्न मान भी सही प्रकार का होगा।

 function parse(str: string) { return str.split(''); } const res1 = parse(42); // ^ Error: Argument of type 'number' is not // assignable to parameter of type 'string' const res2 = parse('hello'); // ^? string[]

कैच वेरिएबल्स में अज्ञात प्रकार

 { "compilerOptions": { "useUnknownInCatchVariables": true } }

useUnknownInCatchVariables को कॉन्फ़िगर करने से ट्राई-कैच ब्लॉक में अपवादों को सुरक्षित रूप से संभालने की अनुमति मिलती है। डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट मानता है कि कैच ब्लॉक में त्रुटि प्रकार any है, जो हमें त्रुटि के साथ कुछ भी करने की अनुमति देता है।

उदाहरण के लिए, हम पकड़ी गई त्रुटि को एक लॉगिंग फ़ंक्शन में पास कर सकते हैं जो Error का उदाहरण स्वीकार करता है।

 function logError(err: Error) { // ... } try { return JSON.parse(userInput); } catch (err) { // ^? any logError(err); }

हालाँकि, वास्तव में, त्रुटि के प्रकार के बारे में कोई गारंटी नहीं है, और हम केवल त्रुटि होने पर रनटाइम पर इसका वास्तविक प्रकार निर्धारित कर सकते हैं। यदि लॉगिंग फ़ंक्शन को कुछ ऐसा प्राप्त होता है जो Error नहीं है, तो इसके परिणामस्वरूप रनटाइम त्रुटि होगी।

इसलिए, useUnknownInCatchVariables विकल्प त्रुटि के प्रकार को any से unknown में बदल देता है ताकि हमें इसके साथ कुछ भी करने से पहले त्रुटि के प्रकार की जांच करने की याद दिला सके।

 try { return JSON.parse(userInput); } catch (err) { // ^? unknown // Now we need to check the type of the value if (err instanceof Error) { logError(err); } else { logError(new Error('Unknown Error')); } }

अब, टाइपस्क्रिप्ट हमें logError फ़ंक्शन को पास करने से पहले err वेरिएबल के प्रकार की जांच करने के लिए प्रेरित करेगा, जिसके परिणामस्वरूप अधिक सही और सुरक्षित कोड प्राप्त होगा। दुर्भाग्य से, यह विकल्प promise.catch() फ़ंक्शंस या कॉलबैक फ़ंक्शंस में टाइपिंग त्रुटियों में मदद नहीं करता है।

लेकिन हम अगले लेख में ऐसे any मामले से निपटने के तरीकों पर चर्चा करेंगे।

कॉल के लिए जाँच और आवेदन के तरीके टाइप करें

 { "compilerOptions": { "strictBindCallApply": true } }

एक अन्य विकल्प call और apply के माध्यम से any इन-फंक्शन कॉल की उपस्थिति को ठीक करता है। यह पहले दो की तुलना में कम सामान्य मामला है, लेकिन इस पर विचार करना अभी भी महत्वपूर्ण है। डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट ऐसे निर्माणों में प्रकारों की बिल्कुल भी जाँच नहीं करता है।

उदाहरण के लिए, हम किसी भी फ़ंक्शन को तर्क के रूप में कुछ भी पास कर सकते हैं, और अंत में, हमें हमेशा any प्रकार प्राप्त होगा।

 function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? any const n2 = parse.call(undefined, false); // ^? any

strictBindCallApply विकल्प को सक्षम करने से टाइपस्क्रिप्ट अधिक स्मार्ट हो जाती है, इसलिए रिटर्न प्रकार को number के रूप में सही ढंग से अनुमानित किया जाएगा। और गलत प्रकार के तर्क को पारित करने का प्रयास करते समय, टाइपस्क्रिप्ट त्रुटि को इंगित करेगा।

 function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? number const n2 = parse.call(undefined, false); // ^ Argument of type 'boolean' is not // assignable to parameter of type 'string'.

निष्पादन संदर्भ के लिए सख्त प्रकार

 { "compilerOptions": { "noImplicitThis": true } }

अगला विकल्प जो आपके प्रोजेक्ट में any की उपस्थिति को रोकने में मदद कर सकता है वह फ़ंक्शन कॉल में निष्पादन संदर्भ के प्रबंधन को ठीक करता है। जावास्क्रिप्ट की गतिशील प्रकृति किसी फ़ंक्शन के अंदर संदर्भ के प्रकार को स्थिर रूप से निर्धारित करना कठिन बना देती है।

डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट ऐसे मामलों में संदर्भ के लिए any प्रकार का उपयोग करता है और कोई चेतावनी नहीं देता है।

 class Person { private name: string; constructor(name: string) { this.name = name; } getName() { return function () { return this.name; // ^ 'this' implicitly has type 'any' because // it does not have a type annotation. }; } }

noImplicitThis कंपाइलर विकल्प को सक्षम करने से हमें फ़ंक्शन के लिए संदर्भ के प्रकार को स्पष्ट रूप से निर्दिष्ट करने के लिए प्रेरित किया जाएगा। इस तरह, उपरोक्त उदाहरण में, हम Person वर्ग के name फ़ील्ड के बजाय फ़ंक्शन संदर्भ तक पहुंचने की त्रुटि को पकड़ सकते हैं।

टाइपस्क्रिप्ट में शून्य और अपरिभाषित समर्थन

 { "compilerOptions": { "strictNullChecks": true } }

अगले कई विकल्प जो strict मोड में शामिल हैं, उनके परिणामस्वरूप कोडबेस में any प्रकार दिखाई नहीं देता है। हालाँकि, वे टीएस कंपाइलर के व्यवहार को सख्त बनाते हैं और विकास के दौरान अधिक त्रुटियाँ पाए जाने की अनुमति देते हैं।

ऐसा पहला विकल्प टाइपस्क्रिप्ट में null और undefined की हैंडलिंग को ठीक करता है। डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट मानता है कि null और undefined किसी भी प्रकार के लिए मान्य मान हैं, जिसके परिणामस्वरूप अप्रत्याशित रनटाइम त्रुटियां हो सकती हैं।

strictNullChecks कंपाइलर विकल्प को सक्षम करने से डेवलपर को उन मामलों को स्पष्ट रूप से संभालने के लिए मजबूर होना पड़ता है जहां null और undefined हो सकते हैं।

उदाहरण के लिए, निम्नलिखित कोड पर विचार करें:

 const users = [ { name: 'Oby', age: 12 }, { name: 'Heera', age: 32 }, ]; const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } console.log(loggedInUser.age); // ^ TypeError: Cannot read properties of undefined

यह कोड त्रुटियों के बिना संकलित होगा, लेकिन यह रनटाइम त्रुटि उत्पन्न कर सकता है यदि "मैक्स" नाम वाला उपयोगकर्ता सिस्टम में मौजूद नहीं है, और users.find() undefined लौटाता है। इसे रोकने के लिए, हम strictNullChecks कंपाइलर विकल्प को सक्षम कर सकते हैं।

अब, टाइपस्क्रिप्ट हमें users.find() द्वारा लौटाए गए null या undefined की संभावना को स्पष्ट रूप से संभालने के लिए बाध्य करेगा।

 const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } | undefined if (loggedInUser) { console.log(loggedInUser.age); }

null और undefiined की संभावना को स्पष्ट रूप से संभालकर, हम रनटाइम त्रुटियों से बच सकते हैं और यह सुनिश्चित कर सकते हैं कि हमारा कोड अधिक मजबूत और त्रुटि मुक्त है।

सख्त कार्य प्रकार

 { "compilerOptions": { "strictFunctionTypes": true } }

strictFunctionTypes सक्षम करने से टाइपस्क्रिप्ट का कंपाइलर अधिक बुद्धिमान हो जाता है। संस्करण 2.6 से पहले, टाइपस्क्रिप्ट फ़ंक्शन तर्कों के विरोधाभास की जाँच नहीं करता था। यदि फ़ंक्शन को गलत प्रकार के तर्क के साथ कॉल किया जाता है तो इससे रनटाइम त्रुटियां हो जाएंगी।

उदाहरण के लिए, भले ही कोई फ़ंक्शन प्रकार स्ट्रिंग और संख्या दोनों को संभालने में सक्षम हो, हम उस प्रकार के लिए एक फ़ंक्शन असाइन कर सकते हैं जो केवल स्ट्रिंग को संभाल सकता है। हम अभी भी उस फ़ंक्शन के लिए एक नंबर पास कर सकते हैं, लेकिन हमें एक रनटाइम त्रुटि प्राप्त होगी।

 function greet(x: string) { console.log("Hello, " + x.toLowerCase()); } type StringOrNumberFn = (y: string | number) => void; // Incorrect Assignment const func: StringOrNumberFn = greet; // TypeError: x.toLowerCase is not a function func(10);

सौभाग्य से, strictFunctionTypes विकल्प को सक्षम करने से यह व्यवहार ठीक हो जाता है, और कंपाइलर कंपाइल-टाइम पर इन त्रुटियों को पकड़ सकता है, जो हमें फ़ंक्शंस में प्रकार की असंगतता का एक विस्तृत संदेश दिखाता है।

 const func: StringOrNumberFn = greet; // ^ Type '(x: string) => void' is not assignable to type 'StringOrNumberFn'. // Types of parameters 'x' and 'y' are incompatible. // Type 'string | number' is not assignable to type 'string'. // Type 'number' is not assignable to type 'string'.

वर्ग संपत्ति आरंभीकरण

 { "compilerOptions": { "strictPropertyInitialization": true } }

अंतिम लेकिन महत्वपूर्ण बात, strictPropertyInitialization विकल्प उन प्रकारों के लिए अनिवार्य क्लास प्रॉपर्टी इनिशियलाइज़ेशन की जाँच करने में सक्षम बनाता है जिनमें मूल्य के रूप में undefined शामिल नहीं है।

उदाहरण के लिए, निम्नलिखित कोड में, डेवलपर email प्रॉपर्टी को प्रारंभ करना भूल गया। डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट इस त्रुटि का पता नहीं लगाएगा, और रनटाइम पर कोई समस्या उत्पन्न हो सकती है।

 class UserAccount { name: string; email: string; constructor(name: string) { this.name = name; // Forgot to assign a value to this.email } }

हालाँकि, जब strictPropertyInitialization विकल्प सक्षम किया जाता है, तो टाइपस्क्रिप्ट हमारे लिए इस समस्या को उजागर करेगा।

 email: string; // ^ Error: Property 'email' has no initializer and // is not definitely assigned in the constructor.

सुरक्षित सूचकांक हस्ताक्षर

 { "compilerOptions": { "noUncheckedIndexedAccess": true } }

noUncheckedIndexedAccess विकल्प strict मोड का हिस्सा नहीं है, लेकिन यह एक और विकल्प है जो आपके प्रोजेक्ट में कोड गुणवत्ता को बेहतर बनाने में मदद कर सकता है। यह इंडेक्स एक्सेस एक्सप्रेशन की जांच को null या undefined रिटर्न प्रकार में सक्षम बनाता है, जो रनटाइम त्रुटियों को रोक सकता है।

निम्नलिखित उदाहरण पर विचार करें, जहां हमारे पास कैश्ड मान संग्रहीत करने के लिए एक ऑब्जेक्ट है। फिर हमें किसी एक कुंजी का मूल्य प्राप्त होता है। निःसंदेह, हमें इसकी कोई गारंटी नहीं है कि वांछित कुंजी का मान वास्तव में कैश में मौजूद है।

डिफ़ॉल्ट रूप से, टाइपस्क्रिप्ट मान लेगा कि मान मौजूद है और उसका प्रकार string है। इससे रनटाइम त्रुटि हो सकती है.

 const cache: Record<string, string> = {}; const value = cache['key']; // ^? string console.log(value.toUpperCase()); // ^ TypeError: Cannot read properties of undefined

टाइपस्क्रिप्ट में noUncheckedIndexedAccess विकल्प को सक्षम करने के लिए undefined रिटर्न प्रकार के लिए इंडेक्स एक्सेस एक्सप्रेशन की जांच करने की आवश्यकता होती है, जो हमें रनटाइम त्रुटियों से बचने में मदद कर सकता है। यह किसी सरणी में तत्वों तक पहुँचने पर भी लागू होता है।

 const cache: Record<string, string> = {}; const value = cache['key']; // ^? string | undefined if (value) { console.log(value.toUpperCase()); }

अनुशंसित विन्यास

चर्चा किए गए विकल्पों के आधार पर, इष्टतम प्रकार की सुरक्षा के लिए आपके प्रोजेक्ट की tsconfig.json फ़ाइल में strict और noUncheckedIndexedAccess विकल्पों को सक्षम करने की अत्यधिक अनुशंसा की जाती है।

 { "compilerOptions": { "strict": true, "noUncheckedIndexedAccess": true, } }

यदि आपने पहले से ही strict विकल्प को सक्षम कर लिया है, तो आप strict: true विकल्प की नकल से बचने के लिए निम्नलिखित विकल्पों को हटाने पर विचार कर सकते हैं:

• noImplicitAny
• useUnknownInCatchVariables
• strictBindCallApply
• noImplicitThis
• strictFunctionTypes
• strictNullChecks
• strictPropertyInitialization

निम्नलिखित विकल्पों को हटाने की भी अनुशंसा की जाती है जो टाइप सिस्टम को कमजोर कर सकते हैं या रनटाइम त्रुटियों का कारण बन सकते हैं:

• keyofStringsOnly
• noStrictGenericChecks
• suppressImplicitAnyIndexErrors
• suppressExcessPropertyErrors

इन विकल्पों पर सावधानीपूर्वक विचार करके और कॉन्फ़िगर करके, आप अपने टाइपस्क्रिप्ट प्रोजेक्ट्स में इष्टतम प्रकार की सुरक्षा और बेहतर डेवलपर अनुभव प्राप्त कर सकते हैं।

निष्कर्ष

टाइपस्क्रिप्ट ने अपने विकास में एक लंबा सफर तय किया है, लगातार अपने कंपाइलर और टाइप सिस्टम में सुधार कर रहा है। हालाँकि, बैकवर्ड संगतता बनाए रखने के लिए, टाइपस्क्रिप्ट कॉन्फ़िगरेशन अधिक जटिल हो गया है, जिसमें कई विकल्प हैं जो टाइप चेकिंग की गुणवत्ता को महत्वपूर्ण रूप से प्रभावित कर सकते हैं।

इन विकल्पों पर सावधानीपूर्वक विचार करके और कॉन्फ़िगर करके, आप अपने टाइपस्क्रिप्ट प्रोजेक्ट्स में इष्टतम प्रकार की सुरक्षा और बेहतर डेवलपर अनुभव प्राप्त कर सकते हैं। यह जानना महत्वपूर्ण है कि प्रोजेक्ट कॉन्फ़िगरेशन से कौन से विकल्प सक्षम और हटाए जाने हैं।

कुछ विकल्पों को अक्षम करने के परिणामों को समझने से आप प्रत्येक के लिए सूचित निर्णय ले सकेंगे।

यह ध्यान रखना महत्वपूर्ण है कि सख्त टाइपिंग के परिणाम हो सकते हैं। जावास्क्रिप्ट की गतिशील प्रकृति से प्रभावी ढंग से निपटने के लिए, आपको एक वेरिएबल के बाद केवल "संख्या" या "स्ट्रिंग" निर्दिष्ट करने से परे टाइपस्क्रिप्ट की अच्छी समझ होनी चाहिए।

उत्पन्न होने वाले प्रकार से संबंधित मुद्दों को अधिक प्रभावी ढंग से हल करने के लिए आपको अधिक जटिल संरचनाओं और पुस्तकालयों और उपकरणों के टाइपस्क्रिप्ट-प्रथम पारिस्थितिकी तंत्र से परिचित होने की आवश्यकता होगी।

परिणामस्वरूप, कोड लिखने में थोड़े अधिक प्रयास की आवश्यकता हो सकती है, लेकिन मेरे अनुभव के आधार पर, दीर्घकालिक परियोजनाओं के लिए यह प्रयास सार्थक है।

मुझे आशा है कि आपने इस लेख से कुछ नया सीखा होगा। यह किसी शृंखला का पहला भाग है. अगले लेख में, हम चर्चा करेंगे कि टाइपस्क्रिप्ट की मानक लाइब्रेरी में प्रकारों में सुधार करके बेहतर प्रकार की सुरक्षा और कोड गुणवत्ता कैसे प्राप्त की जाए। बने रहें, और पढ़ने के लिए धन्यवाद!

उपयोगी कड़ियां

• TSConfig संदर्भ
• किसी भी तरह का
• शून्य और अपरिभाषित