docs: document the Deno install path for the CLI - #3569
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe installation guide adds Deno commands for project scaffolding and global CLI installation. A documentation test validates the guidance and rejects the nonexistent JSR package. ChangesDeno installation guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cae7bfb53b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
cae7bfb to
06bbb6c
Compare
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/getting-started/installation.md`:
- Line 101: Update the Deno heading to sentence-case capitalization in
docs/getting-started/installation.md:101-101, changing it to “### Deno”. Update
the corresponding expected heading in tests/docs/guide-content.test.ts:369-369
to “### Deno”.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f9e5894f-8112-4f69-b288-ee0b7f328925
📒 Files selected for processing (2)
docs/getting-started/installation.mdtests/docs/guide-content.test.ts
The installation guide lists Deno 2.2 or later as a supported runtime and offers `deno add npm:veryfront` for project installs, but neither the "New scaffolded project" CodeGroup nor the "Install the CLI" section had a Deno entry. A Deno user following the page had no documented way to get a global `veryfront` binary, and the only Deno install instruction anywhere in the workspace pointed at `jsr:@veryfront/veryfront`, which 404s -- the CLI is published to npm only. Add the two missing entries, both verified against the published 0.1.1228 release: - `deno init --npm veryfront` in the scaffolding CodeGroup, matching the Deno tab already documented in create-project.md. - A `### deno` subsection with `deno install -gArf npm:veryfront`, plus the caveat that Deno resolves the bare `npm:` specifier from the current working directory, so the global binary reports a project's pinned version when run inside that project.
06bbb6c to
cdec940
Compare
Found during a DX dogfood walk of the public getting-started docs.
Symptom
docs/getting-started/installation.mdlists Deno 2.2 or later as asupported runtime and offers
deno add npm:veryfrontfor project installs,but Deno then disappears from the rest of the page:
npm/pnpm/yarn/buntabs, nodenotab (even though
create-project.mdalready documentsdeno init --npm veryfront).### npm/### pnpm/### yarn/### bun, no### deno.So a Deno user following the page literally has no documented way to get a
global
veryfrontbinary. The only Deno CLI-install instruction anywhere inthe workspace pointed at
jsr:@veryfront/veryfront, which does not exist:Root cause
The CLI is published to npm only —
deno.jsondeclares the unscoped nameveryfront, so no@veryfront/veryfrontJSR package exists or could exist.The working Deno install path goes through Deno's
npm:specifier, and thatone line was simply never added to the installation guide when the Deno tab
was added to the "Blank or existing project" CodeGroup.
Verified against the published 0.1.1228 release, in a sandbox outside the
repo with
DENO_INSTALL_ROOTpointed at a scratch directory:The caveat in the new subsection is also reproduced, not inferred.
deno install -gwrites a shim that runsdeno run npm:veryfront, and Denoresolves that bare specifier against the nearest
package.json/node_moduleswalking up from the current working directory — so theshim's own pinned version is bypassed inside a project that depends on
veryfront:(
/tmp/sb/pinnedpinsveryfront@0.1.1226inpackage.json; the binaryinvoked is the same absolute path in both runs.) Without that note, a Deno
user reasonably concludes the global install silently failed.
Fix
Two additions to
docs/getting-started/installation.md:deno init --npm veryfrontin the "New scaffolded project" CodeGroup,matching the Deno tab already documented in
create-project.md.### denosubsection withdeno install -gArf npm:veryfrontand thecwd-resolution caveat.
No code changes. The related half of this report — the CLI's own update
banner telling users to run
deno install -gArf jsr:@veryfront/veryfront—was already fixed by #3524 (
cli/shared/update-check.tsnow points athttps://registry.npmjs.org/veryfront/latestand printsnpm install -g veryfront@latest), which shipped in 0.1.1228. The walkersaw the old banner from a stale 0.1.1019 binary resolved out of a
node_modulestree above its cwd — the same cwd-resolution mechanismdescribed above.
Regression test
tests/docs/guide-content.test.ts— "gives Deno an install path on everysurface the installation guide offers".
It lives there because that file already owns the installation guide's
runtime-support contract: the adjacent test ("states the supported runtime
floors in the getting-started docs") is what asserts the page's
Deno 2.2 or laterclaim in the first place. Asserting that the claim comes with a usableinstall path belongs directly beside the claim itself, and the file is
filesystem-only so it stays cheap. The test also asserts the page never
reintroduces
jsr:@veryfront/veryfront.Confirmed failing before the fix, for the right reason:
Green after:
deno task docs:validatepasses end to end (48 guide-contracttests, 1226 doc links OK), and the full pre-push suite passed.
Note:
docs/getting-started/**is the source of truth —.github/workflows/sync-docs.ymldispatches to
veryfront/veryfront-docson merge, so the public page picksthis up automatically. No change was made in
veryfront-docs.Summary by CodeRabbit
Documentation
npm:package resolution, and checking the globally installed CLI version.Tests