डॉक्टर

blume doctor बिल्ड करने से पहले ही कॉन्फ़िगरेशन और कंटेंट से जुड़ी समस्याओं का पता लगाता है। यह config, हर पेज, Node संस्करण और सर्वर की आवश्यकता वाली सुविधाओं की जाँच करता है।

blume doctor प्रोजेक्ट को ठीक उसी तरह स्कैन करता है जैसे blume build करता है। यह जो कुछ भी पाता है उसकी रिपोर्ट देता है, पर कुछ भी जनरेट या बिल्ड नहीं करता। जब कोई बिल्ड किसी अस्पष्ट कारण से विफल हो, तो सबसे पहले इसे ही चलाएँ। CI में जाँच के लिए भी यह एक सस्ता विकल्प है:

blume doctor

blume init इसे package.json में doctor स्क्रिप्ट के रूप में भी जोड़ता है। pnpm के साथ इसे pnpm run doctor के रूप में चलाएँ (monorepo रूट से pnpm --filter <workspace> run doctor)। केवल pnpm doctor चलाने पर स्क्रिप्ट के बजाय pnpm का अपना बिल्ट-इन doctor कमांड चलता है।

यह क्या जाँचता है

• Node संस्करण: इंस्टॉल किया गया blume पैकेज Node के जिन संस्करणों को सपोर्ट करता है, उनकी रेंज पैकेज के अपने engines फ़ील्ड से पढ़ी जाती है। Node संस्करण की जाँच इसी रेंज से की जाती है। इस रेंज से बाहर के संस्करण पर चेतावनी मिलती है। ऐसा संस्करण काम कर भी सकता है, लेकिन Blume इस संयोजन का परीक्षण नहीं करता।
• blume.config.ts: इसकी जाँच उसी सत्यापन से होती है जो बिल्ड के दौरान चलता है। अगर कोई key हटा दी गई है या उसका नाम बदल दिया गया है, तो केवल “unrecognized key” नहीं दिखता। उसकी जगह एक संकेत मिलता है जो नई key का नाम बताता है।
• हर कंटेंट पेज और फ़ोल्डर meta: blume dev और blume build प्रोजेक्ट लोड करते समय जो डायग्नोस्टिक्स प्रिंट करते हैं, वे सब यहाँ एक ही रिपोर्ट में मिलते हैं। इनमें अमान्य frontmatter, ऐसा .mdx जो पार्स नहीं हो पाता, नेविगेशन की समस्याएँ, न मिलने वाले include लक्ष्य और बाकी सभी समस्याएँ शामिल हैं।
• ऐसा नेविगेशन जो कहीं नहीं ले जाता: कोई टैब, सिलेक्टर आइटम, फ़ीचर्ड लिंक, हेडर एक्शन या कॉल टू एक्शन, जिसका पाथ किसी पेज, कस्टम .astro पेज, जनरेट किए गए रूट, reference, public/ फ़ाइल या Blume द्वारा जनरेट की जाने वाली फ़ाइल से मेल नहीं खाता। ऐसे में एक चेतावनी (BLUME_NAV_MISSING_PAGE) मिलती है। यह वही चेतावनी है जो blume dev और blume build प्रिंट करते हैं। टैब की जाँच उसी पाथ पर होती है जिस पर वह लिंक करता है: अगर उसमें href है तो उसका href, वरना उसका path।
• <Component> के ऐसे उदाहरण जो मौजूद नहीं हैं: ऐसा path जो examples के अंतर्गत किसी भी फ़ाइल से मेल नहीं खाता। पेज पर ऐसा उदाहरण “No example found” बॉक्स के रूप में दिखता। ऐसे में उसकी पंक्ति पर एक चेतावनी (BLUME_EXAMPLE_NOT_FOUND) मिलती है, ठीक वैसे ही जैसे blume dev और blume build इसे प्रिंट करते हैं। Component नाम का कोई components.ts ओवरराइड या island बिल्ट-इन कंपोनेंट की जगह ले लेता है, और उसकी जाँच नहीं की जाती।
• सर्वर की आवश्यकता वाली सुविधाएँ: स्टैटिक आउटपुट के लिए कॉन्फ़िगर की गई साइट पर असिस्टेंट, MCP सर्वर, Try it playground के बिल्ट-इन प्रॉक्सी या सर्वर-मोड search (Mixedbread) जैसी सुविधाएँ होने पर एक त्रुटि मिलती है। यह त्रुटि सुविधा का नाम बताती है और यह भी बताती है कि आपको किस डिप्लॉयमेंट एडेप्टर पर स्विच करना चाहिए। अगर किसी होस्ट एडेप्टर में output: "static" सेट है, तो यह आपको वह विकल्प हटाने के लिए कहती है।
• आपके config के लिए आवश्यक पैकेज जो इंस्टॉल नहीं हैं: जैसे किसी search, content source, असिस्टेंट या नैरेशन एडेप्टर द्वारा इम्पोर्ट किया गया SDK, किसी डिप्लॉयमेंट एडेप्टर का @astrojs/* पैकेज, या Vue या Svelte islands का renderer। हर पैकेज के लिए एक त्रुटि मिलती है, जिसमें पैकेज का नाम और आपके पैकेज मैनेजर के लिए इंस्टॉल कमांड दी जाती है। blume build भी इसी जाँच पर रुक जाता है।
• ऐसे components.ts ओवरराइड जिनकी योजना Blume नहीं बना सकता: जैसे कोई inline या computed एंट्री, या ऐसा import जिसकी फ़ाइल मौजूद नहीं है। हर ऐसे ओवरराइड के लिए उसकी पंक्ति पर एक त्रुटि मिलती है।
• संस्करण जैसे नाम वाला फ़ोल्डर (v1.0/): अगर साइट पर कोई versions कॉन्फ़िगर नहीं है, तो ऐसा फ़ोल्डर सामान्य कंटेंट की तरह बिल्ड हो जाता। ऐसे में एक चेतावनी मिलती है, जो आपको blume version देखने को कहती है।
• किसी सक्षम सुविधा के लिए ज़रूरी सीक्रेट जो सेट नहीं हैं: जैसे MIXEDBREAD_API_KEY या OPENROUTER_API_KEY। ऐसे में वेरिएबल का नाम बताने वाली एक चेतावनी मिलती है। blume dev और blume build की तरह, Doctor भी सबसे पहले .env और .env.local लोड करता है। यह जाँच किसी भी रिमोट content source द्वारा डेटा फ़ेच किए जाने से पहले होती है। इसलिए अगर बाद में कोई source अपने टोकन के बिना विफल हो जाए, तब भी चेतावनी प्रिंट होती है।

सारांश

डायग्नोस्टिक्स के बाद doctor बताता है कि प्रोजेक्ट की सेटिंग्स अंत में क्या तय हुईं। इससे आप एक नज़र में देख सकते हैं कि आपकी सोची हुई कॉन्फ़िगरेशन और Blume को दिख रही कॉन्फ़िगरेशन में कोई अंतर तो नहीं है। सारांश में ये जानकारियाँ होती हैं: पेजों की संख्या, आउटपुट मोड और डिप्लॉयमेंट एडेप्टर, search प्रदाता, और कॉन्फ़िगर किए गए reference, analytics और content source एडेप्टर। इसमें यह भी दिखता है कि असिस्टेंट चालू है या नहीं, और वह कौन-सा बैकएंड इस्तेमाल करता है।

एग्ज़िट कोड और JSON

अगर error डायग्नोस्टिक्स मौजूद हों, तो Doctor non-zero एग्ज़िट कोड देता है। इसलिए CI उन्हीं समस्याओं पर विफल होता है जिन पर बिल्ड विफल होता। चेतावनियाँ रिपोर्ट में दिखती हैं, पर उनसे CI विफल नहीं होता। --json देने पर डायग्नोस्टिक्स टर्मिनल रिपोर्ट के बजाय stdout पर JSON के रूप में मिलते हैं। इनका ढाँचा वही होता है जो blume validate --json का होता है।