Add docusaurus-plugin-copy-page-button

[portdeveloper]

This PR

• adds docusaurus-plugin-copy-page-button to package.json
• adds the plugin string to plugins in docusaurus.config.ts
• puts a "Copy page" button in the docs sidebar — exports current page as clean markdown
• adds one-click "Open in Claude / ChatGPT / Gemini" actions that prefill the markdown

why useful for Osmosis specifically:
the integrate/ and validate/ sections carry a lot of per-page nuance — pools, IBC transfers, CosmWasm, running and upgrading nodes. the typical flow for someone building against Osmosis or standing up a validator is reading a docs page → wanting to drop just that page into an LLM to scaffold the integration or debug a setup. this saves the selection-and-cleanup step.

zero config, auto-injects into the TOC sidebar, theme-aware. (noticed you swizzle DocSidebar — the button injects near the TOC on the right, so it won't touch your left-nav customizations.)

shipping on React Native, Redux Toolkit, Puppeteer, pnpm, PlayCanvas, Arbitrum, Cardano, Sui, Nillion, Flare, Kaia, and ~20 other docs sites. listed on the Docusaurus community plugins page.

happy to close/rebase if not a fit

• repo: https://github.com/portdeveloper/docusaurus-plugin-copy-page-button
• npm: https://www.npmjs.com/package/docusaurus-plugin-copy-page-button

[vercel]

@portdeveloper is attempting to deploy a commit to the OsmoLabs Team on Vercel.

A member of the Team first needs to authorize it.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	docusaurus-plugin-copy-page-button@​0.8.1

View full report

[JohnnyWyles]

Thanks for this, and for the clear writeup. The underlying goal (making the docs easy to hand to an LLM) is one we care about and will address once the current content pass is finished.

Not 100% on the need to expose this to a user to then copy across to an LLM. At the moment, we're looking more at ways to make the docs work better without a human intermediary, rather than simplifying by having a human copy across pages into context.

On review, generateMarkdownRoutes is the feature that would help with this, but it's off by default and didn't work on our setup. When we enabled generateMarkdownRoutes: true and rebuilt, it emitted zero .md files.

We're going to hold this PR for now, rather than merge the button alone, until after the content sweep, and look into alternative methods for making docs more palatable to LLMs for comparison.

[portdeveloper]

appreciate the detailed feedback — the "no human intermediary" framing is the right one, and generateMarkdownRoutes is exactly the piece for that, so the zero-files thing was a real bug worth chasing.

dug into it: your site sets trailingSlash: false, so docusaurus emits flat <route>.html files instead of the default <route>/index.html. the markdown generator only looked for the nested form, so fs.existsSync missed every page and it silently wrote nothing. the build "succeeded" with zero output, which is why it looked like a no-op rather than an error.

fixed in 0.8.3 (just published) — it now resolves both layouts. i reproduced it on a clone of this branch: with 0.8.3 + generateMarkdownRoutes: true, it went from 0 to 117 .md files, each with the page title, canonical url, and content. no button or human copy-paste involved — just per-page markdown at /<route>.md for whatever consumes it.

totally reasonable to hold until after the content sweep. whenever you revisit, bumping to ^0.8.3 and flipping generateMarkdownRoutes: true should give you the machine-readable routes to compare against the other approaches. happy to help wire it up if useful.

[JohnnyWyles]

Wanted to be straight with you about where we landed, since you put real work in here. We added a small first-party build step (now merged: #351). It generates the same thing, per-page <route>.md plus an llms.txt index, but reads our source markdown directly rather than post-processing the built HTML, which lets us handle a few site-specific things (rewriting relative links and image paths to the shifted route depth, expanding our DocCardList landing pages into child lists, and stripping only the MDX chrome that isn't in code fences). Keeping it in-repo with no added dependency also fit this repo's constraints.

Thank you for raising this with us and the contribution though, this was real missing functionality that if we hadn't had on the radar already would have been really useful with the increasing usage of LLMs for most work.