संदर्भटूलिंगबढ़ रहाअपडेट 2026.08पढ़ने में 6 मिनट
संदर्भ · टूलिंग

जाँचें

हरा बिल्ड इस बात की गारंटी नहीं कि पन्ने ठीक हैं। यह टूलचेन हर परत पर एक जाँच बिठाती है, और हर जाँच "बिल्ड हरा, पन्ना टूटा" वाली ख़ामोश विफलता की एक क़िस्म पकड़ती है — इनमें से दो तो पन्नों को वैसे देखती हैं जैसे पाठक देखता है: असली ब्राउज़र में।

पाँच जाँचें · तीन इंजन से, दो इस पैकेज से · कमिट से पहले सब हरा

§1पाँच द्वार, पाँच परतें

जाँचकहाँ से आती हैक्या देखती हैकब चलाएँ
check-contentइंजन, scripts/check-content.mjsहर md/mdx सोर्स-फ़ाइलसामग्री-रिपॉज़िटरी की CI, या लिखने के बाद
check-wikilinksइंजन, scripts/check-wikilinks.mjs[[विकीलिंक]] का ग्राफ़सामग्री-रिपॉज़िटरी की CI, या नोट का नाम बदलने के बाद
check-distइंजन, scripts/check-dist.mjsastro build का आउटपुटहर बिल्ड के बाद (postbuild)
ui_probeयह पैकेज, scripts/ui_probe.mjsअसली ब्राउज़र में रेंडर हुए पन्नेस्टाइल/लेआउट बदलने के बाद
contrast_probeयह पैकेज, scripts/contrast_probe.mjsहर टेक्स्ट-नोड का कंट्रास्ट, दोनों थीमकिसी भी टोकन-बदलाव के बाद

§2check-content: सोर्स-परत

पन्ना बनने जा रही हर md/mdx को साइट की हूबहू उसी बोली से कंपाइल करती है — सिंटैक्स की ग़लतियाँ और ख़ामोश विरूपण (जोड़ा न बैठने वाले emphasis-चिह्न, MDX-मूल्यांकन में निगले गए braces, लाइन टूटने से जन्मे सूची-चिह्न, एक-लाइन $$, KaTeX से न बनने वाले सूत्र — वही सूची जिस पर kitchen-sink ख़त्म होता है) — सब CI को लाल कर देते हैं।

यह स्क्रिप्ट इंजन से ही क्यों आनी चाहिए: जिस जाँचकर्ता का प्लगइन-सेट साइट से अलग हो, वह जाँचकर्ता न होने से भी बुरा है — गणित-प्लगइन से वंचित जाँचकर्ता सूत्रों के braces को JSX-अभिव्यक्ति पढ़ बैठता है, GFM-रहित जाँचकर्ता टेबलों को यूँ ही जाने देता है। बोली इंजन में एक बार लिखी जाती है; साइट की रेंडरिंग, CMS की सहेजते-वक़्त की जाँच और यह स्क्रिप्ट — तीनों हमेशा वही एक बरतती हैं।

सामग्री-रिपॉज़िटरी की रूट
node <engine>/scripts/check-content.mjs . --glob '**/index.{md,mdx}' --math

कंपाइल से आगे यह frontmatter की दो ख़ामोश हानियाँ भी पकड़ती है: किसी मान में बिना उद्धरण का # (YAML उसे टिप्पणी पढ़कर बाक़ी चुपचाप काट देता है) और ऐसा YAML जो पार्स ही न हो — दोनों लाइन-संख्या समेत रिपोर्ट होते हैं।

मृत [[विकीलिंक]] जान-बूझकर बिल्ड नहीं गिराते — बगीचे को उन नोटों से जुड़ने की छूट चाहिए जो अभी उगे नहीं। पर लिंक-सड़न की जगह फिर भी CI है, इसलिए इंजन एक lint देता है जो हर विकीलिंक को लाइब्रेरी के अपने पार्सर और समाधान-नियमों से हल करता है (उपनाम, brand, शीर्षक, भाषाई मिरर) और लापता, बहु-अर्थी और संदिग्ध-एंकर वाले लिंक रिपोर्ट करता है। --strict मृत लिंकों को असफल exit बना देता है — इस रिपॉज़िटरी की CI इसे ऐसे ही चलाती है:

इस बगीचे की लिंक-जाँच, जैसे CI चलाती है
node scripts/check-links.mjs

§4check-dist: आउटपुट-परत

बने हुए dist/ में हर वह भीतरी संदर्भ, जिस पर पाठक क्लिक कर सकता है, सचमुच मौजूद होना चाहिए। यह जाँच हरे बिल्ड के नीचे के ख़ामोश गड्ढे पकड़ती है:

  • ग़ैर-मौजूद फ़ाइलों की ओर इशारा करते भीतरी लिंक/एसेट (रूट फेरबदल के बाद दर्जनों की तादाद में उगने वाली क़िस्म);
  • ग़ैर-मौजूद id की ओर इशारा करते पन्ना-भीतर एंकर;
  • पाथ में दोहराए गए भाषा-खंड (/en/en/ — i18n के fallback का पहले से prefix लगे रूटों पर एक और prefix चढ़ा देने का क्लासिक नतीजा);
  • <a> के भीतर <a> (HTML-पार्सर बाहरी को जल्दी बंद कर देता है और बटन अपने कार्डों से बाहर लुढ़क जाते हैं);
  • KaTeX की error-तलछट (पन्ने पर सूत्र लाल टेक्स्ट है, बिल्ड फिर भी हरा)।

यह डेमो इसे postbuild में जोड़ता है: हरा npm run build मतलब आउटपुट-जाँच भी पार।

साइट रूट, बिल्ड के बाद (साइट सब-पाथ पर डिप्लॉय हो तो --base दीजिए)
node vendor/astro-inkbrush/scripts/check-dist.mjs dist --base ${DEMO_BASE:-/}

§5रेंडर-परत की प्रोब

सोर्स और आउटपुट दोनों सही होकर भी पन्ना टूटा रह सकता है — क्लासिक मामला: लैंडिंग-कार्ड जिन पर कोई स्टाइलशीट-नियम बैठता ही नहीं, और वे नंगे टेक्स्ट की एक ठुँसी हुई लाइन बनकर रेंडर होते हैं — लिंक और एंकर की जाँचें हरी की हरी रहती हैं, क्योंकि वे रेंडर हुआ पन्ना देखती ही नहीं। ui_probe dist के हर पन्ने पर असली ब्राउज़र चलाती है, viewport की चार चौड़ाइयों पर (1440/1024/768/430), और नापती है: पन्ने का क्षैतिज overflow, अपने कंटेनर से चौड़े तत्व जिनके रहने को कोई स्क्रॉल-बॉक्स नहीं, ऐसी क्लासें जिन्हें कोई स्टाइलशीट-नियम नहीं सजाता, फाँदे गए शीर्षक-स्तर, दोहरी id, alt से वंचित इमेज, और शून्य की ओर इशारा करते पन्ना-भीतर एंकर व aria-controls। यह सिर्फ़ वही रिपोर्ट करती है जो मशीन सिद्ध कर सके — सौंदर्य पर कोई राय नहीं।

लोकल Chrome/Chromium चाहिए
npm run build
node ../scripts/ui_probe.mjs dist   # dist खुद परोसती है; चालू सर्वर जाँचना हो तो baseUrl दीजिए

यह पूरा दस्तावेज़ देखती है — chrome, साइडबार और डायलॉग समेत। हरा होने का मतलब: रिपोर्ट की आख़िरी लाइन SAMPLES WITH FINDINGS: 0 पढ़े (एक sample = एक रूट, एक चौड़ाई पर)।

§6कंट्रास्ट-प्रोब

टोकन AA का दावा करते हैं, तो दावा नापा जाता है — मान नहीं लिया जाता। contrast_probe dist का हर पन्ना असली ब्राउज़र में खोलती है — लाइट और डार्क थीम, डेस्कटॉप और फ़ोन चौड़ाई — और डिफ़ॉल्ट अवस्था में रेंडर हुआ हर टेक्स्ट-रन नापती है: HTML टेक्स्ट, SVG टेक्स्ट और ::before / ::after का उत्पन्न टेक्स्ट; एक प्रतिनिधि पन्ने पर हर <dialog data-probe-open> overlay खोलकर जाँचा जाता है (और वहाँ मिले खोज-बॉक्स में एक क्वेरी टाइप करके) — यह चिह्न साइट की घोषणा है कि डायलॉग जैसा लिखा है वैसा पूरा है। ज़मीन किसी स्टाइलशीट से नहीं पढ़ी जाती; पन्ना हर अक्षर को पारदर्शी करके रेंडर होता है, उसका स्क्रीनशॉट लिया जाता है, और हर रन के नीचे का पिक्सेल ही उसकी ज़मीन है — इसलिए gradient, color-mix() की आभाएँ, पारभासी परतें और रात का पैलेट सब वैसे ही नपते हैं जैसे वे रेंडर होते हैं। रन का अग्रभूमि-रंग तत्व और उसके पुरखों की संचित opacity साथ लेकर चलता है, इसलिए मद्धिम टेक्स्ट उसी ताक़त पर नपता है जिस पर पाठक उसे सचमुच देखता है। hover और focus अवस्थाएँ आँख से परखी जाती हैं, प्रोब से नहीं। छोटा टेक्स्ट 4.5:1 पर कसा जाता है, बड़ा टेक्स्ट (24px, या 18.66px bold) 3:1 पर; जिस रन का रंग पार्स न हो या ज़मीन का नमूना न बने, वह भी finding गिना जाता है। रिपोर्ट बार से नीचे के हर रन का पन्ना, थीम, चौड़ाई, selector, दोनों रंग और अनुपात नाम लेकर बताती है:

बिल्ड के बाद, दोनों थीम
node ../scripts/contrast_probe.mjs dist   # PROBE_THEMES / PROBE_WIDTHS मैट्रिक्स छोटा करते हैं

स्टाइल बदलने की दिनचर्या
पैकेज की स्टाइलशीट या कंपोनेंट में कोई भी बदलाव पहले इस डेमो के बिल्ड से गुज़रता है, फिर आउटपुट पर ui_probe और contrast_probe से — कमिट से पहले सब हरा। डेमो ही पैकेज का टेस्ट-बेड भी है।

शीर्षक, अनुभाग और मुख्य पाठ — इसी भाषा में।
    ↑↓ · Enter · Escastro-inkstone