JavaScript फ़ॉर्मेटर

Prettier इस टूल के फ़ॉर्मेटिंग आउटपुट के लिए सिर्फ़ प्रेरणा नहीं है — यह ख़ुद Prettier पैकेज है, आपके ब्राउज़र में डाउनलोड और चलाया गया बजाय किसी सर्वर पर Node के ज़रिए, तो नतीजा वही एक जैसी कॉन्फ़िगरेशन के साथ लोकल रूप से `npx prettier` चलाने से मिलने वाले आउटपुट से बाइट-दर-बाइट एक जैसा है। यह फ़र्क़ मायने रखता है क्योंकि JavaScript फ़ॉर्मेटिंग का अनुमान लगाना वाक़ई मुश्किल है: इसे सही करने के लिए भाषा को पूरी तरह पार्स करना ज़रूरी है, पैटर्न से मिलाना नहीं, और कोई फ़ॉर्मेटर जो सिर्फ़ Prettier के व्यवहार का अनुमान लगाता है वह किसी प्रोजेक्ट के असली Prettier कॉन्फ़िगरेशन से ठीक उन्हीं किनारे-मामलों में अलग होगा जहाँ यह मायने रखता है — किसी डेकोरेटर के अंदर, कोई जटिल जेनेरिक टाइप, या कोई असामान्य JSX एक्सप्रेशन।

JavaScript में कई ऐसी संरचनाएँ हैं जो ब्रेस और सेमीकोलन गिनने का सरल तरीक़ा सीधे फ़ेल कर देती हैं। टेम्पलेट लिटरल बैकटिक के बीच मनमाना टेक्स्ट रख सकते हैं, जिसमें ऐसे कैरेक्टर शामिल हैं जो बिल्कुल कोड जैसे दिखते हैं — `` `function() { return "not real code"; }` `` एक अकेली स्ट्रिंग वैल्यू है, तीन स्टेटमेंट नहीं, और जो फ़ॉर्मेटर टेम्पलेट लिटरल की सीमाओं का ट्रैक नहीं रखता वह इसे ग़लत समझेगा। रेगुलर एक्सप्रेशन लिटरल इससे भी बुरे हैं: `/{}/` में ऐसे कैरेक्टर हैं जो ब्रेस जैसे दिखते हैं लेकिन असल में रेगुलर एक्सप्रेशन के अपने पैटर्न का हिस्सा हैं, संरचनात्मक सिंटैक्स नहीं। ऑटोमैटिक सेमीकोलन इंसर्शन एक तीसरी परत की मुश्किल जोड़ता है, क्योंकि JavaScript कई संदर्भों में सेमीकोलन छोड़ने देता है और यह नियमों के आधार पर अंदाज़ा लगाता है कि कोई स्टेटमेंट कहाँ ख़त्म होता है, ऐसे नियम जिन्हें कोई भोला लाइन-आधारित फ़ॉर्मेटर सही तरीक़े से दोहरा नहीं सकता। भाषा को असल में एक सही सिंटैक्स ट्री में पार्स करना, जैसा Prettier करता है, यही चीज़ इन तीनों तरह की ग़लतियों से बचाती है — कोई शॉर्टकट फ़ॉर्मेटर जो प्रोडक्शन कोड में इनमें से एक में भी ग़लती करता है वह एक जोखिम है, सुविधा नहीं।

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

टैब बनाम स्पेस, सिंगल बनाम डबल कोटेशन, सेमीकोलन या नहीं — इनमें से कोई भी चुनाव कोड के चलने के तरीक़े पर काफ़ी असर नहीं डालता, और इन पर असहमति कोड रिव्यू चर्चाओं में असली समय ले लेती थी जिसका सही होने से कोई लेना-देना नहीं था। Prettier का असली मूल्य यह पूरी बहस को मेज़ से हटा देना है: हर जगह अपने आप और एक जैसे लागू होने वाले फ़ॉर्मेटिंग नियमों का एक छोटा, अपनी राय वाला सेट यह मतलब रखता है कि बहस एक बार, कॉन्फ़िगरेशन में हल हो जाती है, बजाय इसके कि यह हर पुल रिक्वेस्ट में बार-बार दोहराई जाए।

यहाँ दिखाया गया हर विकल्प — इंडेंटेशन चौड़ाई, सेमीकोलन, कोटेशन स्टाइल — किसी असली Prettier कॉन्फ़िगरेशन सेटिंग को दर्शाता है, तो किसी जाने-पहचाने `.prettierrc` वाले प्रोजेक्ट से कोड पेस्ट करना और यहाँ वही सेटिंग मिलाना ठीक वही देता है जो उस प्रोजेक्ट का अपना टूल देता — बिना यह जाँचने के लिए कि कोई टुकड़ा कैसे फ़ॉर्मेट होगा, लोकल रूप से कुछ भी इंस्टॉल किए बिना।