Skip to content

docs(web/guides): add Installing with CommandBox support-tier page#3198

Merged
bpamiri merged 1 commit into
developfrom
peter/docs-installing-with-commandbox
Jun 13, 2026
Merged

docs(web/guides): add Installing with CommandBox support-tier page#3198
bpamiri merged 1 commit into
developfrom
peter/docs-installing-with-commandbox

Conversation

@bpamiri

@bpamiri bpamiri commented Jun 13, 2026

Copy link
Copy Markdown
Collaborator

What

Adds a new v4-0-0 guides page, Installing with CommandBox (web/sites/guides/src/content/docs/v4-0-0/start-here/installing-with-commandbox.mdx), plus sidebar entry and cross-links. Part of the ForgeBox/CommandBox path-repair campaign.

Why

The v4 guides contained zero box install mentions (verified: grep -rl 'box install' .../v4-0-0/ → 0 files), even though release.yml publishes four ForgeBox packages (wheels-base-template, wheels-core, wheels-cli, wheels-starter-app) on every stable release. CommandBox-centric 2.x/3.x teams had no answer to "what is my supported workflow on Wheels 4?"

What the page states (the support tier, explicitly)

  • Supported: install the framework via ForgeBox — box install wheels-base-template pulls wheels-core into vendor/wheels/; box server start serves it; reload URL + engine pinning documented. box install wheels-core for vendoring/upgrading an existing app.
  • Not supported via CommandBox: the wheels CLI feature set — generators, migrate, test, console, MCP, the packages registry (CLI-only, not ForgeBox), deploy — install the LuCLI wheels binary (brew/scoop/apt/yum/manual JAR) for those.
  • Legacy-slug note: the wheels-cli ForgeBox module is deprecated (removal in v5), points at the 4.x slugs and wheels new.
  • 2.x/3.x → 4.0 mapping table.

Written to the campaign target end-state (assumes keystone template fix #3176/#3173 and core fix #3177 land). #3177 is already on develop — tools/build/core/box.json uses directory=vendor + packageDirectory=wheels, and the base template's installPaths puts wheels-core in vendor/wheels/.

{test:*} policy

The verify-docs harness only spawns the wheels binary — it cannot run box. Per the policy (harness ignores any block without a {test:*} meta flag; lib/extract.mjs if (!parsed) continue;), all box command blocks are marked illustrative (untagged with descriptive titles). Verified against the same approach already used by cfml-engines.mdx.

Evidence

  • Defect reproduced: grep -rl 'box install' web/sites/guides/src/content/docs/v4-0-0/ → 0 files before this change.
  • pnpm verify:docs (via node scripts/verify-docs/verify-docs.mjs <new page>): EXIT=0, 0 passed, 0 failed, found 0 tagged block(s) — box blocks correctly ignored as illustrative.
  • Combined run over the new page + edited installing.mdx + cfml-engines.mdx: 1 passed, 0 failed (the 1 is the pre-existing wheels --version {test:cli} block in installing.mdx).
  • Sidebar JSON re-validated with json.load after the edit.
  • Cross-link targets/anchors confirmed to exist (upgrading/3x-to-4x/, digging-deeper/packages/, command-line-tools/installation/#manual-jar-install).

No changelog fragment — docs-only change (build-pipeline + CI + docs changes get none).

Fixes #3183.
Refs #3176, #3173, #3177.

🤖 Generated with Claude Code

…3183)

The v4-0-0 guides contained zero `box install` mentions, leaving
CommandBox-centric 2.x/3.x teams with no answer to "what is my supported
workflow now?" despite release.yml publishing four ForgeBox packages on
every stable release.

Add a new start-here page that states the support tier explicitly:
- Supported: install the framework via ForgeBox
  (`box install wheels-base-template` -> wheels-core in vendor/wheels/)
  and serve it (`box server start`, reload URL, engine pinning).
- Not supported via CommandBox: the `wheels` CLI feature set
  (generators, migrate, test, console, MCP, packages registry, deploy) —
  install the LuCLI `wheels` binary from brew/scoop/apt/yum for those.
- Legacy-slug note: `wheels-cli` ForgeBox module is deprecated
  (removal in v5); points at the 4.x slugs.
- 2.x/3.x box-workflow -> 4.0 mapping table.

Written to the campaign target end-state (assumes #3176/#3173 keystone
template fix and #3177 core box.json fix land — #3177 already on develop:
core box.json uses directory=vendor + packageDirectory=wheels, base
template installPaths puts wheels-core in vendor/wheels/).

Box command blocks are marked illustrative (untagged) per the {test:*}
policy — the verify-docs harness only runs the `wheels` binary, not
`box`, so they are correctly ignored. Adds the sidebar entry and
cross-links from installing.mdx and cfml-engines.mdx.

pnpm verify:docs on the page exits 0 (0 tagged blocks).

Fixes #3183.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Peter Amiri <peter@alurium.com>
@bpamiri bpamiri enabled auto-merge (squash) June 13, 2026 03:45
@bpamiri bpamiri merged commit 825ef70 into develop Jun 13, 2026
13 of 14 checks passed
@bpamiri bpamiri deleted the peter/docs-installing-with-commandbox branch June 13, 2026 03:50
bpamiri added a commit that referenced this pull request Jun 24, 2026
…ect to wheels-base-template (#3253)

The Installing with CommandBox page existed to give 2.x/3.x CommandBox
teams a clear Wheels 4 answer, but it never mentioned the slug a
migrating 2.x user actually has in muscle memory:
`box install cfwheels-base-template`. That pre-rebrand slug still
resolves on ForgeBox (76,754 installs, top 'cfwheels' search hit) but
errors on its missing `cfwheels` core dependency and leaves an
unrunnable skeleton.

Worse, the 2.x/3.x migration table claimed
`box install wheels-base-template` + `wheels-core` was 'Unchanged' —
inaccurate for a genuine 2.x user, whose slug DID change
(cfwheels-base-template -> wheels-base-template). The row now reads
'Slug changed' and a caution Aside maps the dead cfwheels- prefixed
slugs to the supported 4.x slugs (cfwheels-base-template ->
wheels-base-template, cfwheels -> wheels-core).

Refs #3198 (post-merge review finding)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Peter Amiri <petera@pai.com>
Co-authored-by: Peter Amiri <petera@pai.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment