docs(site): add vitepress-plugin-llms for llms.txt generation#10086
docs(site): add vitepress-plugin-llms for llms.txt generation#10086ivy wants to merge 2 commits into
Conversation
Generates llms.txt, llms-full.txt, and per-page .md alongside the existing HTML output, following the llmstxt.org standard. Uses the plugin's zero-config defaults — it picks up our site title, description, and sidebar structure from the existing VitePress config, so no plugin options were needed. Pinned to 1.13.0 to match the exact-version style already used for vitepress and vitepress-plugin-mermaid; can be relaxed to a caret range to align with vite/vue/vitest docs sites if preferred.
Registers the bundled CopyOrDownloadAsMarkdownButtons Vue component globally and wires the copyOrDownloadAsMarkdownButtons markdown-it plugin so a "Copy page" dropdown + download icon appear after the H1 on every doc page. Both ship with vitepress-plugin-llms; no new deps.
There was a problem hiding this comment.
Code Review
This pull request integrates the vitepress-plugin-llms package into the documentation site, registering its Vite plugin, markdown plugin, and the global CopyOrDownloadAsMarkdownButtons component. The reviewer suggested utilizing the transform option in the llmstxt() plugin configuration to dynamically replace custom Vue components with their Markdown representations during the build process, ensuring clean source files and accurate LLM-friendly output.
| ruby: "logos:ruby", | ||
| }, | ||
| }), | ||
| llmstxt(), |
There was a problem hiding this comment.
To address the rendering of custom components like <Settings /> and <Registry /> in the LLM-friendly output (as mentioned in your PR description), you can leverage the transform option provided by vitepress-plugin-llms. This allows you to dynamically replace these Vue components with their Markdown representations during the build process, avoiding the need for manual partials or <llm-only> tags.
For example, you can configure it like this:
llmstxt({
transform: async (content, path) => {
if (path.endsWith('configuration/settings.md')) {
// Dynamically import or require the settings data and format it as Markdown
const { renderSettingsMarkdown } = await import('./settings-renderer');
return content.replace('<Settings />', renderSettingsMarkdown());
}
return content;
}
}),This keeps the source markdown files clean and ensures that the LLM-friendly output always has up-to-date settings/registry documentation.
There was a problem hiding this comment.
Oh! That might be another way too. Seems better than updating all of the Markdown docs too. 🤔
Greptile SummaryThis PR integrates
Confidence Score: 4/5Safe to merge once The plugin integration itself is correct and matches the official documentation. The only actionable gap is that
Important Files Changed
Reviews (1): Last reviewed commit: "docs(site): add copy/download-as-markdow..." | Re-trigger Greptile |
| "typescript-eslint": "^8.58.2", | ||
| "vitepress": "1.6.4", | ||
| "vitepress-plugin-group-icons": "^1.6.5", | ||
| "vitepress-plugin-llms": "1.13.0", |
There was a problem hiding this comment.
bun.lock not updated
vitepress-plugin-llms was added to package.json but bun.lock was not committed with the corresponding entry. Anyone who installs from this state will trigger a lockfile regeneration, which also resolves the plugin's transitive dependencies (including the patches it applies) without the integrity hashes being pinned. Running bun install and committing the updated bun.lock would make the resolution reproducible.
I want to make it easier for agents to read the Mise docs. This PR uses vitepress-plugin-llms to add an
/llms.txt(overview + sitemap),.mdvariants of the docs, and a copy widget:Note
<Settings />and<Registry />components don't actually render anything —/configuration/settings.mdis a paragraph then… nothing. Could use some feedback before I fix that.Rendering settings/registries
There's a few options but the cleanest seems to be rendering a partial and including it. One for settings, one for registries (to be honest, I didn't look much at registries).
For settings, we'd render a
docs/_partials/settings.mdfromdocs/settings.data.tsand updatedocs/configuration/settings.mdwith something like:We might have to update the docs that reference the
<Settings />component to have something like:I had ideas for some "smarter" ways, but the most reasonable alternative seemed awful (parsing
<Settings />and its attributes with regex to search/replace with constructed Markdown 🥴).Why vitepress-plugin-llms
Other notes:
llms.txtgeneration functionality vuejs/vitepress#4692 but didn't get any traction.