सत्यापन

blume validate आपकी सामग्री के हर लिंक की जाँच करता है। इसमें पेज, एंकर, एसेट और वैकल्पिक रूप से बाहरी URL शामिल हैं। कोई लिंक टूटा होने पर यह CI को विफल कर देता है।

blume validate आपकी सामग्री को उसी तरह पढ़ता है जैसे बिल्ड पढ़ता है, और उसमें मिलने वाले हर लिंक की जाँच करता है। यह कुछ भी जनरेट या बिल्ड नहीं करता। इसलिए यह एक तेज़ जाँच है जिसे आप blume build से पहले चला सकते हैं:

blume validate

• आंतरिक पेज लिंक (/guides/intro, ./sibling) किसी वास्तविक पेज पर रिज़ॉल्व होने चाहिए। टूटे हुए लिंक त्रुटियों के रूप में रिपोर्ट किए जाते हैं। Markdown और MDX जिन भी रूपों में लिंक रेंडर करते हैं, उन सभी को पढ़ा जाता है: इनलाइन लिंक, जिनमें वह लिंक भी शामिल है जिसका लेबल अगली पंक्ति तक चला जाता है; रेफ़रेंस-स्टाइल लिंक, जिनकी जाँच उनकी [label]: /target परिभाषा पर होती है (जब किसी लेबल को दो बार परिभाषित किया गया हो, तो पहली परिभाषा पर, क्योंकि वही रेंडर होती है); ऑटोलिंक (<https://…>, .md में); और किसी कॉम्पोनेंट का स्ट्रिंग href (<Card href="./install">)। आपकी सामग्री की किसी Markdown फ़ाइल के रूट-रिलेटिव लिंक (/guides/setup.md) की जाँच उस पेज पर होती है जिसे वह फ़ाइल प्रकाशित करती है, क्योंकि बिल्ड उसे वहीं पॉइंट करता है। अगर उस नाम की कोई फ़ाइल वहाँ नहीं है, तो लिंक की जाँच पेज की Markdown कॉपी के रूप में होती है। किसी लिंक का लक्ष्य उसी तरह पढ़ा जाता है जैसे रेंडरर उसे पढ़ता है, इसलिए [x](<https://example.com/a(b>) https://example.com/a(b की ओर इशारा करता है और ![](image\(1\).png) image(1).png की ओर। लक्ष्य के आसपास स्पेस हो सकते हैं, और उसके बाद किसी भी तरह के कोट्स ("…", '…' या (…)) में एक टाइटल हो सकता है। कोड में मौजूद लिंक (फ़ेंस्ड, जिसमें ब्लॉक कोट के अंदर का फ़ेंस भी शामिल है, या इनलाइन) और टिप्पणियों में मौजूद लिंक (.md में <!-- … -->, .mdx में {/* … */}) कभी रेंडर नहीं होते, इसलिए उनकी जाँच नहीं होती। किसी पेज की ओर इशारा करने वाला लोअरकेस HTML <a href> ठीक वैसा ही शिप होता है जैसा लिखा गया है, इसलिए उसकी जाँच उसी तरह होती है जैसे ब्राउज़र उसे पढ़ता है: रिलेटिव पाथ पेज के URL के सापेक्ष रिज़ॉल्व होता है, और कोई basePath नहीं जोड़ा जाता (रूट-रिलेटिव पाथ में, हर लिंक की तरह, डिप्लॉयमेंट base जुड़ जाता है)। href={…} एक्सप्रेशन की जाँच नहीं होती।
• एंकर लिंक (#section, /guides/intro#setup) लक्ष्य पेज के किसी एंकर से मेल खाने चाहिए। यह एंकर किसी हेडिंग का id (जनरेट किया गया या पिन किया गया), किसी raw HTML एलिमेंट का id एट्रिब्यूट, या कोई <a name> हो सकता है। जो एंकर मेल नहीं खाते, वे चेतावनियों के रूप में रिपोर्ट किए जाते हैं। कोड ब्लॉक, इनलाइन कोड, HTML टिप्पणियों और <Prompt> ब्लॉक के अंदर के id नहीं गिने जाते।
• अन्य लिंक स्कीम (mailto:, tel:, किसी ऐप का vscode: डीप लिंक) की जाँच नहीं होती, क्योंकि यह पता नहीं लगाया जा सकता कि पाठक का ब्राउज़र या कोई इंस्टॉल किया गया ऐप उन्हें हैंडल करेगा या नहीं। ReadMe की अपनी लिंक स्कीम इसका अपवाद हैं: doc:, ref:, page:, changelog: और blog: केवल ReadMe पर रिज़ॉल्व होती हैं और बाकी हर जगह डेड लिंक के रूप में शिप होती हैं, इसलिए इनमें से हर एक को चेतावनी के रूप में रिपोर्ट किया जाता है। इनके बजाय पेज को उसके पाथ से लिंक करें।
• एसेट लिंक की जाँच वहीं होती है जहाँ फ़ाइल रखी होती है। एब्सोल्यूट पाथ (/logo.png) को public/ डायरेक्टरी में खोजा जाता है। रिलेटिव इमेज एम्बेड (![](./diagram.png), या किसी कार्ड का <Card img="./cover.png">) को पेज के अपने फ़ोल्डर में खोजा जाता है। किसी भी अन्य फ़ाइल के रिलेटिव लिंक ([spec](./spec.pdf), या कोई <a href> या किसी कॉम्पोनेंट का href) की जाँच भी पेज के अपने फ़ोल्डर में होती है, क्योंकि Blume उस फ़ाइल को पेज के साथ वहीं प्रकाशित करता है। अगर लिंक में दी गई फ़ाइल पेज वाले फ़ोल्डर में नहीं है, तो लिंक public/ के सापेक्ष साइट रूट के रूप में रिज़ॉल्व होता है। किसी मीडिया एलिमेंट (<img>, <source>, <video> या <audio>, चाहे .md में raw HTML के रूप में हो या .mdx में एलिमेंट के रूप में) के src की जाँच भी इसी तरह होती है: रिलेटिव src को पहले पेज वाले फ़ोल्डर में खोजा जाता है। वहाँ न मिलने पर उसे public/ में उस जगह खोजा जाता है जहाँ से ब्राउज़र उसका अनुरोध करता है। जिस प्रोजेक्ट में कोई public/ फ़ोल्डर नहीं होता, वह कोई पब्लिक फ़ाइल शिप नहीं करता, इसलिए वहाँ हर एब्सोल्यूट एसेट पाथ को अनुपस्थित के रूप में रिपोर्ट किया जाता है। .html लिंक (./setup.html, /guides/setup.html) भी फ़ाइल लिंक ही होता है: Blume पेजों को उनके रूट पर सर्व करता है, .html URL पर कभी नहीं। इसलिए अगर public/ में वह फ़ाइल नहीं है, तो लिंक रिपोर्ट किया जाता है। अगर कोई पेज उस लिंक से मेल खाता है, तो सुधार के रूप में उस पेज का रूट सुझाया जाता है।
• रीडायरेक्ट लक्ष्य, यानी redirects में दिए गए लक्ष्य, किसी मौजूद जगह तक ले जाने चाहिए। एक्ज़ैक्ट आंतरिक to को किसी पेज, फ़ाइल या किसी अन्य रीडायरेक्ट तक ले जाना चाहिए। पैटर्न वाले to को ऐसे पाथ तक ले जाना चाहिए जिसके स्थिर शुरुआती हिस्से (/v2/:slug* में /v2/) के अंतर्गत कुछ सर्व होता हो। जो रीडायरेक्ट कहीं नहीं ले जाता, उसे चेतावनी के रूप में रिपोर्ट किया जाता है, और उसका स्थान blume.config.ts में उसके to पर बताया जाता है। किसी रीडायरेक्ट के from की ओर इशारा करने वाला लिंक दोनों ही स्थितियों में मान्य है। बाहरी लक्ष्यों की जाँच नहीं होती।
• बाहरी लिंक की जाँच केवल --external के साथ होती है। यह डिफ़ॉल्ट रूप से बंद रहता है, क्योंकि इसके लिए नेटवर्क चाहिए। डेड लिंक को त्रुटि माना जाता है: 404 या 410, या ऐसा होस्ट नाम जो रिज़ॉल्व नहीं होता। विफल होने वाली बाकी हर स्थिति को चेतावनी माना जाता है, क्योंकि ऐसा अक्सर लिंक के बजाय दूसरी साइट या नेटवर्क की वजह से होता है: कोई भी अन्य त्रुटि स्टेटस (बॉट को रोकने वाली साइट से 401 या 403, 429 रेट लिमिट, 5xx आउटेज), अस्वीकृत या टूटा हुआ कनेक्शन, या 10 सेकंड के भीतर कोई जवाब न मिलना। जिन URL की जाँच उस जगह से नहीं हो सकती जहाँ कमांड चलता है, जैसे कोई प्लेसहोल्डर डोमेन, कोई लोकल सर्वर या बॉट को रोकने वाली कोई साइट, उन्हें बाहर रखने के लिए --ignore पास करें। ऐसा खाली URL, जिसे GitHub-flavored Markdown अपने आप लिंक बना देता है और जिसके आसपास कोई लिंक सिंटैक्स नहीं होता, पढ़ा नहीं जाता। blume audit --external बिल्ड की गई साइट में उसकी जाँच करता है।

पेज किसे माना जाता है

लिंक केवल Markdown पेजों से नहीं, बल्कि बिल्ड की गई साइट द्वारा सर्व की जाने वाली हर चीज़ से रिज़ॉल्व होते हैं। इसमें ये शामिल हैं: कस्टम .astro पेज, API रेफ़रेंस पेज, जनरेट किया गया चेंजलॉग इंडेक्स और हर कॉन्फ़िगर किया गया रीडायरेक्ट। बहुभाषी साइट पर हर लोकेल के अंतर्गत किसी अनअनूदित पेज का फ़ॉलबैक URL भी शामिल है। Blume आपके पेजों के साथ जो फ़ाइलें लिखता है, वे भी गिनी जाती हैं, बशर्ते कॉन्फ़िग में वे चालू हों। ये फ़ाइलें हैं: /llms.txt और /llms-full.txt, साइटमैप, /robots.txt, RSS फ़ीड, /openapi.json, /agent-readability.json, /skill.md और .well-known डिस्कवरी फ़ाइलें, जैसे /.well-known/agent-skills/index.json। public/ में ऐसा फ़ोल्डर भी गिना जाता है जिसमें index.html हो। जैसे कोई स्टैटिक होस्ट उसे सर्व करता है, वैसे ही public/demo/index.html /demo या /demo/ पर उपलब्ध होता है। जो पेज लोड नहीं हो पाता, जैसे अमान्य फ़्रंट मैटर वाला पेज या ऐसा .mdx जो पार्स नहीं होता (BLUME_MDX_SYNTAX), उसे लिंक से जुड़ी समस्याओं के साथ रिपोर्ट किया जाता है। ऐसा इसलिए, क्योंकि जो पेज कभी लोड ही नहीं होता, उसके लिंक जाँचे नहीं जा सकते। उसे सही परिणाम मान लेना ग़लत होगा।

फ़्लैग

• --external — नेटवर्क के ज़रिए बाहरी http(s) लिंक की भी जाँच करता है।
• --ignore <glob> — --external के साथ, जिस बाहरी लिंक का URL ग्लोब से मेल खाता है, उसके लिए अनुरोध नहीं भेजता और उसके बारे में कुछ भी रिपोर्ट नहीं करता। ग्लोब का मिलान लिंक के पूरे URL से किया जाता है, जिसमें स्कीम भी शामिल है: * एक पाथ सेगमेंट के भीतर मेल खाता है और ** कई सेगमेंट में। इसलिए --ignore "https://api.acme.example/**" उस होस्ट के हर लिंक को छोड़ देता है और --ignore "http://localhost:*/**" हर लोकल सर्वर को। अधिक पैटर्न के लिए फ़्लैग को दोहराएँ, और हर पैटर्न को कोट्स में रखें ताकि आपका शेल उसे एक्सपैंड न करे। आंतरिक लिंक की जाँच हमेशा होती है: वे आपके अपने पेजों से रिज़ॉल्व होते हैं, इसलिए टूटे हुए लिंक को ठीक करें या एक रीडायरेक्ट जोड़ें।
• --strict — चेतावनियों पर भी नॉन-ज़ीरो कोड के साथ बाहर निकलता है। Info-स्तर के नोट्स केवल सलाह के रूप में रहते हैं।
• --json — टर्मिनल रिपोर्ट के बजाय डायग्नोस्टिक्स को JSON के रूप में stdout पर देता है।

डायग्नोस्टिक्स

एग्ज़िट कोड ही तय करता है कि जाँच सफल रही या नहीं। त्रुटियाँ होने पर कमांड नॉन-ज़ीरो कोड के साथ बाहर निकलता है। --strict के साथ चेतावनियों पर भी ऐसा ही होता है।

JSON आउटपुट

--json के साथ, blume validate (और blume doctor) stdout पर एक ऑब्जेक्ट लिखते हैं। इसमें एक diagnostics सूची होती है। सूची की हर प्रविष्टि में ये फ़ील्ड होते हैं:

• उसका code, severity और message
• प्रोजेक्ट रूट के सापेक्ष file, और जब समस्या का स्थान पता हो तो line और column
• एक suggestion
• एक docsUrl, जो उस कोड को समझाने वाले पेज की ओर इशारा करता है

इसके अलावा ऑब्जेक्ट में एक summary भी होता है, जिसमें हर गंभीरता स्तर की गिनती होती है। एग्ज़िट कोड वही रहता है। इसलिए एक ही कमांड CI की जाँच भी कर सकता है और एडिटर इंटीग्रेशन को डेटा भी दे सकता है।