स्टैटिक विश्लेषण

स्टैटिक विश्लेषण एक तरह की टेस्टिंग है, जो आपके कोड को असल में चलाए बिना या ऑटोमेटेड टेस्ट लिखने की ज़रूरत के बिना ही उसकी अपने-आप जांच करने की सुविधा देती है. VSCode जैसे IDE का इस्तेमाल करने पर, आपको इस तरह की टेस्टिंग पहले भी दिख सकती है. TypeScript से टाइप की जांच एक तरह का स्टैटिक विश्लेषण होता है. साथ ही, यह गड़बड़ियों या चेतावनियों के तहत घुमावदार लाइनों के तौर पर दिख सकता है.

ESLint

ESLint एक ऐसा टूल है, जो आपके कोडबेस में संभावित समस्याओं पर सुझाव दे सकता है. ये समस्याएं टाइपसुरक्षित हो सकती हैं,लेकिन गड़बड़ियां या गैर-मानक व्यवहार अपने आप में हो सकते हैं. ESLint आपको अपने कोडबेस पर जाँचे जाने वाले कई नियम लागू करने की सुविधा देता है, जिनमें इसके "सुझाए गए" सेट वाले कई नियम शामिल हैं.

ESLint नियम का सबसे अच्छा उदाहरण नहीं-असुरक्षित-आखिर का नियम है. यह आपको ऐसे स्टेटमेंट लिखने से रोकता है जो finally ब्लॉक के अंदर आपके प्रोग्राम के कंट्रोल फ़्लो को बदलता है. यह एक बहुत अच्छा नियम है, क्योंकि ऐसा करना JavaScript लिखने का एक असामान्य तरीका है, जिसे फ़ॉलो करना मुश्किल हो सकता है. हालांकि, कोड की समीक्षा की एक अच्छी प्रोसेस से भी इस बात का पता लगाया जा सकता है.

  try {
    const result = await complexFetchFromNetwork();
    if (!result.ok) {
      throw new Error("failed to fetch");
    }
  } finally {
    // warning - this will 'overrule' the previous exception!
    return false;
  }

उदाहरण के लिए, ESLint एक अच्छी समीक्षा की प्रक्रिया (और एक स्टाइल गाइड जो आपके कोडबेस की तरह दिखना चाहिए) की जगह नहीं ले सकता, क्योंकि इसमें हर उस असामान्य तरीके को शामिल नहीं किया जा सकता जिसे कोई डेवलपर आपके कोडबेस में दिखाने की कोशिश कर सकता है. Google की अंग्रेज़ी प्रैक्टिस गाइड में "इसे आसान बनाए रखने" के बारे में एक छोटा सेक्शन दिया गया है.

ESLint आपको किसी नियम को तोड़ने और कोड को "अनुमति है" के रूप में एनोटेट करने की सुविधा देता है. उदाहरण के लिए, पिछले लॉजिक को इस तरह से एनोटेट करके अनुमति दी जा सकती है:

  finally {
    // eslint-disable-next-line no-unsafe-finally
    return false;
  }

अगर आपको लगता है कि आप किसी नियम का बार-बार उल्लंघन कर रहे हैं, तो उसे बंद करें. ये टूल आपको एक खास तरह से कोड लिखने के लिए प्रोत्साहित करते हैं. हालांकि, ऐसा हो सकता है कि आपकी टीम को अलग तरीके से कोड लिखने के लिए इस्तेमाल किया जाए और उसे इस तरह के जोखिम के बारे में पहले से पता हो.

आखिर में, एक बड़े कोडबेस पर स्टैटिक विश्लेषण टूल को चालू करने से, हो सकता है कि उस कोड के बजाय ग़ैर-ज़रूरी आवाज़ें कम हो जाएं (और रीफ़ैक्टर करने में बहुत ज़्यादा समय लग सकता है). इसलिए, किसी प्रोजेक्ट के लाइफ़साइकल की शुरुआत में इसे चालू करना आसान होता है.

ब्राउज़र में मदद के लिए ESLint प्लगिन

आपके पास ESLint में एक ऐसा प्लगिन जोड़ने का विकल्प है जो उन एपीआई के इस्तेमाल को फ़्लैग करता है जो ज़्यादातर काम नहीं करते या आपकी टारगेट ब्राउज़र सूची के साथ काम नहीं करते. आपके उपयोगकर्ताओं के लिए कोई एपीआई उपलब्ध न होने पर, eslint-plugin-compat पैकेज के ज़रिए आपको चेतावनी दी जा सकती है. इसका मतलब है कि आपको हमेशा खुद ही ट्रैक करने की ज़रूरत नहीं है.

स्टैटिक विश्लेषण के लिए टाइप की जांच

JavaScript सीखते समय, नए डेवलपर को आम तौर पर इस बात का आइडिया मिलता है कि यह खराब तरीके से टाइप की गई भाषा है. इसका मतलब है कि किसी वैरिएबल को एक ही टाइप के तौर पर बताया जा सकता है और फिर किसी दूसरी चीज़ के लिए एक ही जगह का इस्तेमाल किया जा सकता है. यह Python और अन्य स्क्रिप्टिंग भाषाओं के जैसा है. हालांकि, यह C/C++ और Rust जैसी कंपाइल्ड लैंग्वेज से अलग है.

शुरुआत करने के लिए इस तरह की भाषा अच्छी हो सकती है—और यकीनन यह उस आसानी की वजह से JavaScript को इतना लोकप्रिय बना दिया गया है—लेकिन यह अक्सर कुछ कोड बेस के लिए नाकामयाब होता है या कम से कम कुछ ऐसी चीज़ होती है जिससे भ्रम की स्थिति पैदा होती है. उदाहरण के लिए, जहां उम्मीद के मुताबिक string या ऑब्जेक्ट टाइप number पास करता है वहां गलत तरीके से टाइप की गई वैल्यू, अलग-अलग लाइब्रेरी से कॉपी हो सकती है. इससे TypeError की गड़बड़ी खत्म हो जाती है.

TypeScript

टाइपस्क्रिप्ट, JavaScript की टाइपिंग जानकारी की कमी की सबसे मुख्यधारा वाला समाधान है. इस कोर्स में इसका भरपूर इस्तेमाल किया जाता है. हालांकि, यह TypeScript का कोर्स नहीं है, लेकिन यह आपके टूलबॉक्स का एक अहम हिस्सा हो सकता है, क्योंकि यह स्टैटिक विश्लेषण उपलब्ध कराता है.

एक छोटे से उदाहरण के लिए, यह कोड उम्मीद करता है कि string नाम और उम्र number को स्वीकार करने वाला कॉलबैक दिया जाए:

const callback = (name: string, age: string): void => {
  console.info(name, 'is now', age, 'years old!');
};
onBirthday(callback);

TypeScript के ज़रिए चलाने पर या किसी IDE में माउस घुमाने पर, यह गड़बड़ी जनरेट करता है:

bad.ts:4:12 - error TS2345: Argument of type '(name: string, age: string) => void' is not assignable to parameter of type '(name: string, age: number) => void'.
  Types of parameters 'age' and 'age' are incompatible.
    Type 'number' is not assignable to type 'string'.

4 onBirthday(callback);
             ~~~~~~~~

Found 1 error in bad.ts:4

कुल मिलाकर, TypeScript का इस्तेमाल करने का मकसद इस तरह की गड़बड़ियों को रोकना है— उम्र एक number होनी चाहिए, न कि string—अपने प्रोजेक्ट में आने वाले. दूसरी तरह की जांच से इस तरह की गड़बड़ी का पता लगाना मुश्किल हो सकता है. इसके अलावा, टाइप सिस्टम, टेस्ट के लिखे जाने से पहले ही सुझाव दे सकता है. इससे सॉफ़्टवेयर डेवलप करते समय टाइप की गड़बड़ियों के बारे में शुरुआती सुझाव मिलता है, न कि कोड के आखिर में चलने पर. इससे कोड लिखने की प्रोसेस आसान हो जाती है.

TypeScript का इस्तेमाल करने का सबसे मुश्किल हिस्सा, इसे सही तरीके से सेट अप करना है. हर प्रोजेक्ट के लिए एक tsconfig.json फ़ाइल की ज़रूरत होती है, जिसे मुख्य रूप से tsc कमांड-लाइन टूल इस्तेमाल करता है. इसे VSCode जैसे आईडीई, पढ़ते हैं. साथ ही, इसे Vitest के साथ-साथ कई दूसरे बिल्ड टूल और टूल की मदद से भी पढ़ा जाता है. इस फ़ाइल में सैकड़ों विकल्प और फ़्लैग मौजूद हैं और इसे सेट अप करने के लिए आपको कुछ अच्छे संसाधन यहां मिल सकते हैं:

• tsconfig.json क्या है
• TypeScript बेस के लिए सेंट्रलाइज़्ड सुझाव
• TS के साथ अपने JS की जांच करना

सामान्य TypeScript सलाह

किसी tsconfig.json फ़ाइल के ज़रिए TypeScript को सेट अप और इस्तेमाल करते समय, इन बातों का ध्यान रखें:

• पक्का करें कि आपकी सोर्स फ़ाइलें असल में शामिल हों और उनकी जांच की गई हो. अगर किसी फ़ाइल में रहस्यमयी तरीके से "कोई गड़बड़ी नहीं है", तो ऐसा शायद इसलिए है क्योंकि उसकी जांच नहीं की जा रही है.
• फ़ंक्शन लिखते समय, .d.ts फ़ाइलों में टाइप और इंटरफ़ेस के बारे में साफ़ तौर पर जानकारी देने से, उनकी जांच करना आसान हो जाता है. अगर शामिल इंटरफ़ेस साफ़ हैं, तो कोड के मॉक और 'नकली' वर्शन लिखना आसान होता है. .

TypeScript इंप्लिसिट कोई भी

TypeScript का सबसे ताकतवर और फ़ायदेमंद कॉन्फ़िगरेशन विकल्प noImplicitAny फ़्लैग है. हालांकि, अक्सर इसे चालू करना भी सबसे मुश्किल होता है, खास तौर पर तब, जब आपके पास पहले से ही एक बड़ा कोड बेस हो. (अगर आप strict मोड में हैं, तो noImplicitAny फ़्लैग डिफ़ॉल्ट रूप से चालू होता है. अगर ऐसा नहीं है, तो यह चालू नहीं होता है.)

यह फ़्लैग इस फ़ंक्शन से गड़बड़ी दिखाएगा:

export function fibonacci(n) {
  if (n <= 1) {
    return 0;
  } else if (n === 2) {
    return 1;
  }
  return fibonacci(n - 1) + fibonacci(n - 2);
}

हालांकि, एक पाठक के तौर पर यह साफ़ तौर पर पता है कि n एक संख्या होनी चाहिए. TypeScript इसकी पुष्टि नहीं कर सकता. अगर VSCode का इस्तेमाल किया जा रहा है, तो फ़ंक्शन पर कर्सर घुमाने से इसकी जानकारी इस तरह दिखेगी:

function fibonacci(n: any): any

इस फ़ंक्शन को इस्तेमाल करने वाले कॉलर, सिर्फ़ number ही नहीं, बल्कि any टाइप की वैल्यू (ऐसे टाइप जो किसी अन्य तरह की वैल्यू इस्तेमाल करने की अनुमति देते हैं) की वैल्यू पास कर पाएंगे. noImplicitAny फ़्लैग को चालू करके, आप डेवलपमेंट के दौरान इस तरह के कोड को सुरक्षित रख सकते हैं. इसके लिए, आपको खास जगहों पर गलत डेटा टाइप पास करने वाले कोड के लिए, बड़े पैमाने पर बिज़नेस लॉजिक टेस्ट लिखने की ज़रूरत नहीं होगी.

इसका आसान तरीका यह है कि आप n तर्क और fibonacci के रिटर्न टाइप, दोनों को number के तौर पर मार्क करें.

noImplicitAny फ़्लैग, आपको अपने कोड बेस में साफ़ तौर पर any लिखने से नहीं रोकता है. आपके पास अब भी ऐसा फ़ंक्शन लिखने का विकल्प है जो any टाइप को स्वीकार करता हो या दिखाता हो. इससे बस यह पक्का होता है कि आप हर वैरिएबल को एक टाइप दें.