Repository navigation
docs: offer npm/yarn/bun for every install command (#402) - #453
Conversation
Wraps 46 command blocks across 12 guides in <PackageManagerTabs>, so readers on npm, yarn or bun stop translating pnpm commands by hand. The component derives the other three from the authored pnpm fence, and the shared tab group means a choice made on one page — or in the homepage hero — is already selected on all the others. Fixes a live error while it is here. installation.md had three hand-written sections: "Using npm (recommended)" sitting above a `pnpm add` command, a "Using pnpm" section that was a byte-for-byte duplicate of it, and no bun at all. So the page told npm readers to run pnpm. All three collapse into one component that renders the correct command for each. No inbound links referenced the removed anchors. Four commands were authored outside the component's vocabulary and are rewritten into it, which changes what pnpm users see only in that `pnpm dev` becomes the equivalent `pnpm run dev`: pnpm dev -> pnpm run dev (7 blocks) npm start -> pnpm run start (2 blocks, CRA setups) npm install -D purgecss -> pnpm add -D … npm uninstall node-sass -> pnpm remove … Deliberately not converted: - `contributing.md` (9 blocks). These are monorepo commands — `pnpm exec`, `--filter`, `audit`, `approve-builds`, `why` — which are not package-manager verbs, so the component's round-trip assertion rejects them and the build fails. It is also the wrong advice: this repo pins pnpm via `packageManager`, so a contributor has no npm/yarn/bun equivalent to offer. - `npx skills add …` (9 blocks). That is the command the skills ecosystem documents; rewriting it to `pnpm dlx` form to fit our component would be the tail wagging the dog. - `npm view` / `npm list` — informational, not installs. They would render identically on all four tabs. - Three blocks with a blank line inside the fence. `splitSegments` drops empty segments, so they cannot round-trip; leaving them as plain fences preserves the visual grouping the blank line is there for. - `api/elements/pre.md` (a live <Pre> demo, not an instruction) and the stock Docusaurus tutorial pages. Every converted block is checked at build time: the component derives the authored command back out of the fence and throws unless it renders to exactly what is written, so a bad conversion fails the prerender rather than shipping three wrong tabs. Closes #402 Claude-Session: https://claude.ai/code/session_01TGA6sFTUGsJ6oXhfpjKEnh
|
Warning Review limit reached
Next review available in: 18 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (12)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Preview DeploymentPreview URL: https://86ab55d9.bestax.pages.dev |
|
🎉 This PR is included in version 4.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 5.8.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 2.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
Pull Request
Description
Wraps 46 command blocks across 12 guides in
<PackageManagerTabs>, so readers on npm, yarnor bun stop translating pnpm commands by hand. The component derives the other three from the
authored pnpm fence, and the shared tab group means a choice made on one page — or in the
homepage hero from #434 — is already selected everywhere else.
Fixes a live error on the way
installation.mdhad three hand-written sections:### Using npm (recommended)sitting above apnpm addcommand### Using pnpmsection that was a byte-for-byte duplicate of itSo the page told npm readers to run pnpm. All three collapse into one component that renders
the correct command per manager. No inbound links referenced the removed anchors (checked
across
docs/,skills/, the packages and the README).Four commands rewritten into the authoring vocabulary
The component authors in pnpm's verb vocabulary and derives the rest, so these had to move into
it. The only visible change for pnpm readers is
pnpm dev→ the equivalentpnpm run dev:pnpm devpnpm run devnpm startpnpm run startnpm install -D @fullhuman/postcss-purgecsspnpm add -D …npm uninstall node-sasspnpm remove …Deliberately not converted
Worth reading, because two of these are correctness constraints rather than taste:
contributing.md(9 blocks). These are monorepo commands —pnpm exec,--filter,audit,approve-builds,why— which aren't package-manager verbs, so the round-tripassertion rejects them and the build fails. I verified this:
It's also the wrong advice: the repo pins pnpm via
packageManager, so a contributor has nonpm/yarn/bun equivalent to be offered.
npx skills add …(9 blocks) — the command the skills ecosystem documents. Rewriting itto
pnpm dlxform to fit our component would be the tail wagging the dog.npm view/npm list— informational, not installs; they'd render identically on allfour tabs.
Three blocks with a blank line inside the fence.
splitSegmentsdrops empty segments, sothey can't round-trip. Left as plain fences, which preserves the visual grouping the blank
line exists for. This is a real limitation of the component worth knowing about.
api/elements/pre.md(a live<Pre>demo, not an instruction) and the stock Docusaurustutorial-basics/tutorial-extraspages.bulma-ui (
@allxsmith/bestax-bulma)create-bestax (
create-bestax)docs (
@allxsmith/bestax-docs)Related Issue(s)
Closes #402
Type of Change
installation.mdnpm/pnpm error)Verification
Every converted block is checked at build time. The component derives the authored command
back out of the fence and throws unless it renders to exactly what was written, so a bad
conversion fails the prerender rather than shipping three wrong tabs. The build passing is
the assertion that all 46 are correct.
Also checked:
react-setups.mdhas 19 blocks inside numbered list items. I probedthat shape before converting anything: all four tabs render, the
<ol>survives, and the LLMartifact keeps the fence at its list indentation.
installation.mdnow renders all four (pnpm add/npm install/yarn add/bun add)and the wrong heading is gone.
pnpm run check:conformance— 0 violations;check:urls— all 6 resolve; docs tests 21/21;prettier clean.
Additional Context
The LLM artifacts keep the pnpm fence by construction — the plugin strips the wrapper and
leaves the code block — so
llms.txtshows exactly what a reader sees on the default tab. Nobuild step involved; see
docs/CLAUDE.md.