Configuration

हर theme option आपके jsdoc.json में opts के नीचे रहता है (या TypeDoc के लिए, typedoc.json में cleanJsdocTheme block के नीचे — ठीक नीचे JSDoc vs TypeDoc देखें)। बाक़ी build सेट करना JSDoc Getting Started और TypeDoc Getting Started में बताया गया है; यह page theme के अपने options का दस्तावेज़ है।

नीचे हर option दोनों tools का snippet tabs में दिखाता है — जो आपके setup से मेल खाए वही चुनें।

अनजान या ग़लत-वर्तनी वाले options default रूप से सिर्फ़ चेतावनी देते हैं (एक "did you mean?" संकेत के साथ) — build जारी रहता है। उन चेतावनियों को errors में बदलने के लिए strict सेट करें।

JSDoc vs TypeDoc

इस page का हर option दोनों tools के लिए एक जैसा है — सिर्फ़ आप उसे कहाँ रखते हैं यह अलग है। JSDoc में theme options opts के नीचे जाते हैं; TypeDoc में, cleanJsdocTheme के नीचे।

theme options opts के नीचे, JSDoc के अपने options के साथ रहते हैं:

कोड
{
  source: { include: ["./src", "./README.md"] },
  plugins: ["plugins/markdown"],
  opts: {
    destination: "dist",
    recurse: true,
    template: "node_modules/clean-jsdoc-theme/dist",
    // ↓ theme options
    siteName: "My Library",
    sectionOrder: ["Getting Started", "Classes", "Modules"],
    clubSidebarItems: true,
    copyPage: { enabled: true, actions: ["copy", "view", "claude"] },
  },
}

option के नाम और values एक जैसे हैं — सिर्फ़ namespace बदलता है: opts (JSDoc) बनाम cleanJsdocTheme (TypeDoc)। एक अपवाद: outputSourceFiles और sourceLinkToComment options JSDoc के templates.default के नीचे बैठते हैं और सिर्फ़ JSDoc के लिए हैं।

Site & identity

siteName

header में दिखने वाला title — सादा text, या एक logo image।

अपेक्षित: एक string, या एक logo set object। logo set की keys सभी strings हैं: light और dark हर theme में इस्तेमाल होने वाले logo URLs (या local paths) हैं, default वह fallback है जब theme-विशिष्ट न दिया गया हो, और alt वह text है जो image load न होने पर दिखता है (और screen readers द्वारा पढ़ा जाता है)।

कोड
opts: { siteName: "My Library" }
// या एक logo जो theme के साथ बदलता है:
opts: {
  siteName: {
    light: "./assets/logo.svg",
    dark: "./assets/logo-dark.svg",
    alt: "My Library",
  },
}

Default रूप से आपके package के name पर।

basePath

वह site root path जिसे renderer हर internal link और asset के आगे जोड़ता है — इसे तब सेट करें जब site domain root के बजाय किसी sub-path के नीचे serve हो।

अपेक्षित: एक string path। Default "" (root पर serve)।

कोड
opts: { basePath: "/my-library" } // example.com/my-library/ पर serve

siteUrl

आपकी site का सार्वजनिक base URL। सेट होने पर, build output root पर एक sitemap.xml emit करता है — हर page के लिए एक entry (hidden source-viewer pages को छोड़कर) — जिसे आप search engines को submit कर सकते हैं या robots.txt से reference कर सकते हैं। इसके बिना कोई sitemap नहीं बनता।

अपेक्षित: एक पूर्ण http(s) URL। हर page के URL के लिए केवल इसका origin इस्तेमाल होता है; deploy sub-path basePath से आता है, इसलिए दोनों कभी double-count नहीं होते — एक सादा origin (https://example.com) और एक पूरा URL जिसका path आपके basePath के बराबर हो (https://example.com/my-library), दोनों एक ही सही <loc> entries देते हैं। कोई sitemap न चाहिए तो इसे छोड़ दें (default)।

कोड
opts: { siteUrl: "https://example.com", basePath: "/my-library" }
// → https://example.com/my-library/… URLs वाला sitemap.xml

favicon

एक favicon image का path। bridge इसे एक content-hashed _assets/ asset में copy करता है और हर page के <head> में एक <link rel="icon"> emit करता है (एक type के साथ जो extension से निकाला जाता है — .svgimage/svg+xml)।

अपेक्षित: एक string file path (.svg, .png, .ico, …), working dir के सापेक्ष। छोड़ा गया → कोई favicon link नहीं।

कोड
opts: { favicon: "./assets/logo-small.svg" }

एक SVG favicon को इस option की ज़रूरत होती है — browsers केवल एक root favicon.ico को auto-discover करते हैं, कभी किसी SVG को नहीं। एक SVG icon SVG के अंदर एक @media (prefers-color-scheme: dark) block के साथ light/dark के अनुसार ढल भी सकता है।

Content sources

readme

एक Markdown file जो site का home page बनकर render होती है।

अपेक्षित: एक path string। (एक root docs/index.md इसे override कर देता है — docs देखें।)

कोड
opts: { readme: "./README.md" }

docs

हाथ से लिखे Markdown/HTML guides की एक directory जो prose pages के रूप में render होती है। folder का layout हर page का URL और sidebar group तय करता है; प्रति-file YAML frontmatter (title, group, order, slug, hidden) defaults को override करता है, और एक root index.md home page बन जाती है।

अपेक्षित: एक path string (एक directory)।

कोड
opts: { docs: "./docs" }

docGroups

sidebar में top-level doc groups का प्रदर्शन-क्रम।

अपेक्षित: group-label strings की एक array।

कोड
opts: { docGroups: ["Getting Started", "Guides"] }

यही site docs और docGroups options से बनी है — इसके guides सादा Markdown files हैं जो उन्हीं sidebar sections में समूहित हैं जिन्हें आप अभी देख रहे हैं। कुछ ऐसा ही बनाना चाहते हैं? source देखें: docs-site on GitHub

defaultDocGroup

वह group label जिसमें कोई doc तब आता है जब वह कोई group घोषित न करे (न frontmatter group, न humanize करने योग्य कोई folder)।

अपेक्षित: एक अकेली string।

कोड
opts: { defaultDocGroup: "Docs" }

tutorials

JSDoc की --tutorials directory। हर tutorial एक guide page बनता है, sidebar में "Tutorials" के नीचे समूहित।

अपेक्षित: एक path string (एक directory)। JSDoc के -u flag के समतुल्य।

कोड
opts: { tutorials: "./tutorials" }

sectionOrder

सभी top-level sidebar sections का क्रम — आपके doc/category groups और API kind labels (Classes, Modules, …) दोनों। सूचीबद्ध labels दिए गए क्रम में पहले आते हैं; जो आप छोड़ देते हैं वह उसके बाद जुड़ जाता है।

अपेक्षित: section-label strings की एक array।

कोड
opts: { sectionOrder: ["Getting Started", "Guides", "Classes", "Modules"] }

JSDoc के तहत sectionOrder doc/tutorial groups और API kind sections को क्रमित करता है। TypeDoc के तहत इसका बिल्कुल कोई प्रभाव नहीं — वह sidebar एक अपने स्थिर क्रम वाला module/folder पदानुक्रम है, और वहाँ doc groups docGroups से क्रमित होते हैं, sectionOrder से नहीं। देखें TypeDoc flavor

clubSidebarItems

संबंधित entries (जैसे एक module और उसके members) को एक साझा, collapsible parent के नीचे समेटें, पहले / से पहले वाले path segment के अनुसार समूहित।

अपेक्षित: एक boolean। Default false

clubSidebarItems का TypeDoc API tree पर कोई प्रभाव नहीं पड़ता। देखें TypeDoc flavor

कोड
opts: { clubSidebarItems: true }

sidebar navigation के ऊपर pin किए गए custom links।

अपेक्षित: entries की एक array। हर एक एक object है जिसमें title, एक link (या href), एक वैकल्पिक id, और एक वैकल्पिक iconlucide:<name> या simpleicons:<name>, एक CDN से load होता है। दो वैकल्पिक fields link की presentation को नियंत्रित करते हैं: target (link target — external link डिफ़ॉल्ट रूप से _blank) और class (rendered link पर merge की गई अतिरिक्त CSS class(es))।

कोड
opts: {
  menu: [
    { title: "Home", link: "/", icon: "lucide:home" },
    { title: "GitHub", link: "https://github.com/you/repo", icon: "simpleicons:github" },
    // उसी tab में खोलें + customCss से styling के लिए एक custom class दें:
    { title: "Changelog", link: "/changelog", target: "_self", class: "menu-changelog" },
  ],
}

हर content page के नीचे का prev/next pager — दो cards जो sidebar reading order में आसपास के pages को link करते हैं। Default में on; source-viewer pages कभी नहीं दिखाते।

अपेक्षित: एक boolean shorthand, या एक object { enabled }। Default true

कोड
opts: { pageNav: false }
// या object रूप: opts: { pageNav: { enabled: false } }

Appearance & assets

fonts

type families को override करें।

अपेक्षित: एक object जिसमें heading, body, और/या mono हों। heading और body Google Font family नाम हैं (आपके लिए load होते हैं, build के समय अस्तित्व जाँचा जाता है); mono एक CSS font stack है।

कोड
opts: {
  fonts: { heading: "Fraunces", body: "Spline Sans", mono: "Spline Sans Mono" },
}

colors and darkColors

theme को फिर से रंगें। colors light-mode palette है (और :root default भी); darkColors dark-mode palette है, जो [data-theme="dark"] के नीचे emit होती है। हर एक built-in palette पर प्रति key merge होती है, इसलिए आप सिर्फ़ bg override करके बाक़ी हर default रख सकते हैं।

अपेक्षित: इन keys के किसी भी subset वाला एक object, हर एक एक CSS color string (theme oklch के साथ आता है, पर कोई भी मान्य CSS color चलता है):

Keyभूमिका
bgPage background
bgMutedहल्की सतहें (code blocks, cards, sidebar)
fgBody text
fgMutedद्वितीयक / muted text
accentLinks, focus rings, primary buttons
accentFgaccent background पर text/icon
borderमहीन रेखाएँ और dividers
codeHeaderBgCode-block header strip background
codeHeaderFgCode-block header label text
codeHighlightBgHighlighted code-line background (@playground / highlight=)

तीनों code* keys code-block chrome को style करती हैं — header strip (इसका background + CODE/filename label) और किसी highlighted line पर tint। ये light में एक neutral #f7f7f7-समतुल्य पर और dark में elevated greys पर default होती हैं, इसलिए आप इन्हें केवल किसी custom palette से मेल खाने के लिए सेट करते हैं।

कोड
opts: {
  colors: { bg: "oklch(0.99 0.01 95)", accent: "oklch(0.55 0.2 250)" },
  darkColors: { bg: "oklch(0.18 0.01 250)", accent: "oklch(0.7 0.16 250)" },
}

अनजान keys और non-string values को नज़रअंदाज़ कर दिया जाता है। अगर आप darkColors पूरी तरह छोड़ देते हैं, तो dark mode colors के एक समझदार bg/fg अदला-बदली पर fallback कर जाता है।

customCss and customJs

हर page में inject किए गए inline CSS/JS। custom CSS theme stylesheet के बाद load होती है (ताकि override करे); custom JS सबसे आख़िर में चलता है।

अपेक्षित: एक string।

कोड
opts: { customCss: ".my-banner { color: rebeccapurple; }" }

customCssFile and customJsFile

ऊपर जैसा ही, पर disk पर एक file से पढ़ा जाता है। bridge हर एक को एक content-hashed asset में copy करके link करता है।

अपेक्षित: एक path string।

कोड
opts: { customCssFile: "./extra.css", customJsFile: "./extra.js" }

hashCustomAssets

क्या custom-asset filenames content-hashed हों (cache-busting के लिए)। स्थिर, बिना-hash वाले नाम रखने के लिए false सेट करें।

अपेक्षित: एक boolean। Default true

कोड
opts: { hashCustomAssets: false }

LLM & copy page

copyPage

प्रति-page "copy page" / "open in LLM" button (सिर्फ़ content pages)।

अपेक्षित: एक boolean shorthand, या एक object { enabled, actions } जहाँ actions में से कोई भी हो: copy, view, claude, chatgpt, perplexity। Default में on, सभी actions के साथ।

कोड
opts: { copyPage: { enabled: true, actions: ["copy", "view", "claude"] } }
// या बस: opts: { copyPage: false }

aiPrompt

एक custom निर्देश जो तब आगे जोड़ा जाता है जब किसी page को open-in actions के ज़रिये किसी LLM को सौंपा जाता है।

अपेक्षित: एक string।

कोड
opts: { aiPrompt: "You are helping a developer use My Library. " }

Source files

ये दोनों सिर्फ़ JSDoc के लिए हैं। ये templates.default (JSDoc का default-template namespace) के नीचे रहते हैं, opts या cleanJsdocTheme के नीचे नहीं।

outputSourceFiles

क्या syntax-highlighted source-file viewer pages और members पर Source: file:line links generate हों।

अपेक्षित: एक boolean। Default true; दोनों को दबाने के लिए false सेट करें।

कोड
templates: { default: { outputSourceFiles: false } }

sourceLinkToComment

कोई Source: link कहाँ उतरता है: symbol की declaration (default) या उसका documentation comment

अपेक्षित: एक boolean। Default false (declaration पर उतरता है)।

कोड
templates: { default: { sourceLinkToComment: true } }

How assets are handled

इसे आप configure नहीं करते, पर यह जानना अच्छा है कि आपके docs और README से referenced local files कैसे process होती हैं। कोई भी image जिसे आप किसी relative या root-relative path से link करते हैं — ![diagram](./assets/flow.svg) — site की _assets/ directory में एक content-hashed नाम (जैसे _assets/flow.3de65053.svg) के तहत copy हो जाती है और reference उसकी ओर इंगित करने के लिए फिर से लिखा जाता है। hash file के bytes से निकाला जाता है, इसलिए अपरिवर्तित file builds के बीच एक स्थिर, cacheable URL रखती है और बदली हुई file अपने-आप cache-bust हो जाती है। बाहरी (https://…) और data: URLs अछूते रहते हैं।

.svg files को एक अतिरिक्त चरण मिलता है: उनका markup <img> के ज़रिये load होने के बजाय सीधे page में inline कर दिया जाता है। इससे किसी SVG की अपनी [data-theme="dark"] styles in-page theme toggle का अनुसरण कर पाती हैं — एक <img> से load हुई SVG सिर्फ़ operating system का color scheme देख सकती है, आपके site का toggle कभी नहीं।

Logos (siteName) और customCssFile / customJsFile उसी content-hashed _assets/ pipeline पर चलते हैं।

Localization

ये दोनों आपकी site को एक बहु-भाषी build में बदल देते हैं — हर locale के लिए एक static site, जिसमें एक header language switcher और hreflang alternates जुड़े होते हैं। ये locales घोषित करते हैं; असल translation workflow (catalogs निकालना, translate करना, और हर locale को build करना) clean-jsdoc CLI से चलता है। पूरा walkthrough Localize your docs में है। बिना locales के build पर कोई असर नहीं पड़ता — वह ठीक पहले जैसा ही render होता है।

localized builds आज सिर्फ़ JSDoc के लिए हैं। TypeDoc bridge catalogs extract तो कर सकता है पर अभी per-locale sites render नहीं करता।

locales

build की जाने वाली भाषाएँ।

अपेक्षित: { code, name } objects की एक array (name switcher का label है), या सादे locale-code strings। Codes BCP-47-ish होते हैं (en, pt-BR)।

कोड
opts: {
  locales: [
    { code: "en", name: "English" },
    { code: "ja", name: "日本語" },
  ],
}

defaultLocale

site root पर render होने वाली भाषा (बाक़ी हर locale /<code> के नीचे उतरती है)।

अपेक्षित: एक locale code जो locales में मौजूद हो। वैकल्पिक — default रूप से पहली entry।

कोड
opts: { defaultLocale: "en" }

Build

strict

option diagnostics (एक ख़राब font नाम, एक अनजान key) को चेतावनियों से कठोर build errors में बढ़ा दें।

अपेक्षित: एक boolean। Default false

कोड
opts: { strict: true }

progress

build का progress output (प्रति-stage spinners) toggle करें।

अपेक्षित: एक boolean। Default true

कोड
opts: { progress: false }