Feature: CLI Support for Self-Hosted Player Builds from Installation Selections

[R-Delfino95]

Note

Triage estimate — cycle priority and story points were assigned during an AI-assisted planning pass and are rough first guesses. Confirm or adjust when you pick this up.

Add CLI support for turning the installation-guide selections (framework, skin, media renderer, source URL) into a self-hosted player build: a generated entrypoint that imports the selected player configuration, plus a documented bundler command that produces a single file the user can serve without a CDN dependency.

This is the third outcome from #1637. PR #1680 covered the first two outcomes for HTML as docs only, and deferred this CLI work as a follow-up.
Today users hand-stitch the documented esbuild recipe; this would take them from selection to a self-hosted build in one step, reusing the selection model the docs already expose.

Relationship to the CLI epic (#247)

This is distinct from the epic's init command in intent:

• init (as described in Epic: Video.js CLI Platform and Project Initialization #247) scaffolds Video.js into a project for development — detects framework/style, prompts for skin/eject, adds markup + styles, installs deps. Output: your project, wired up at the source level.
• This issue produces a deployable, self-hosted artifact — a bundled file you serve yourself, for offline / air-gapped / corporate environments where CDNs are barred (the original use case from the Docs: Self-Hosted Builds #1637 Discord thread). Output: a built dist/player.js.

Open question — command shape

A. A mode/flag of init (a different output target of the same command):

npx @videojs/cli init --self-hosted

B. A separate command focused only on the deployable artifact:

npx @videojs/cli build --skin default --media hls --source-url <url>
# emits dist/player.js (+ index.html) ready to serve, no CDN dependency

Tasks

• Decide the command shape: a mode of init vs. a separate command
• Accept the installation selection flags (--framework, --preset, --skin, --media, --source-url) and prompt interactively when omitted
• Generate the entrypoint + package.json / bundler config for the chosen selection
• Wire up and document the bundler command that produces the self-hosted single-file build
• Keep the generated output consistent with the "Self-host the player" docs section

[github-actions]

Planning recommendations

• Epic: Fits cleanly under Epic: Video.js CLI Platform and Project Initialization #247 (Feature: CLI Package) — this adds the `create`/`init` command the epic anticipates.
• Blocked by: docs(site): document self-hosted and offline player builds #1680 — the PR that documents the "Self-host the player" section (the source-of-truth recipe this generator must reproduce) should land first.
• Milestone: Strong fit for GA (2026-07-31); the self-hosted build path is part of the documented installation story being shipped with v10.
• Priority: P2 — meaningful DX improvement, but not blocking core playback functionality.
• Related: Docs: Self-Hosted Builds #1637 (parent epic for self-hosted docs), Feature: Sandbox CLI and Framework Playground #1073 (Sandbox CLI playground, adjacent CLI work).

[github-actions]

Planning notes

• Epic: recommend linking to Epic: Video.js CLI Platform and Project Initialization #247 (CLI Package) — this is clearly scoped as a sub-issue of that epic.
• Blocked by: recommend formalizing the dependency on docs(site): document self-hosted and offline player builds #1680 — the "Self-host the player" docs section is the source-of-truth recipe this CLI command must reproduce, so it should land first.
• Command shape (the open question): the needs discussion label has been added. The decision between init --self-hosted (option A) and a standalone build command (option B) gates all implementation tasks, so coordinating with the Epic: Video.js CLI Platform and Project Initialization #247 epic owner is the logical first step.
• Milestone: the GA milestone (due 2026-07-31) is likely too tight for this — it's a DX improvement that isn't a GA-critical blocker. Recommend leaving it unscheduled for now and revisiting post-GA alongside the other CLI sub-issues (Feature: Docs CLI Command #1215, Source-Owned UI #1055, Feature: Sandbox CLI and Framework Playground #1073).
• Priority: suggest P2 — valuable DX improvement for air-gapped/offline deployments, but no existing functionality is broken.

[github-actions]

Planning Recommendations

Epic linkage: This belongs under #247 (Feature: CLI Package) — recommend linking it as a child issue of that epic.

Blocked by / follows: #1680 (docs PR) is the direct predecessor; #1637 is the parent problem. Consider noting this as a follow-on to #1637's third outcome.

Related CLI issues to plan alongside:

• Feature: Sandbox CLI and Framework Playground #1073 (Feature: Sandbox CLI and Framework Playground) — overlapping CLI infrastructure
• Source-Owned UI #1055 (Feature: Eject) — generates project-level files from selections, adjacent scope

Command shape decision: The open question (flag on init vs. separate build command) is the key blocker. Coordinating with the #247 epic owner before implementation starts will prevent conflicting CLI surface designs.

Roadmap: Recommend adding to the roadmap once the command shape is resolved with the #247 epic owner.

Priority: P2 — meaningful DX gap for air-gapped/corporate deployments, but not blocking core functionality.