Wire up Linux/macOS/BDS deploy targets in scaffolder

[joeskeen]

Summary

The scaffolder currently hardcodes "target": "retail" in the generated config.json (src/templates/custom/config.json:14-17) and prints "deploy to local Minecraft (Windows)" in the next-steps banner (src/cli/index.js:65). Today, that scaffold only works on Windows — the compiler (Keyyard/bedrock-build) throws exit 3 on any other OS. The companion compiler issue (Keyyard/bedrock-build#1) fixes the resolution side. This issue tracks the scaffolder follow-on: a new prompt, copy edits, and the fallback bump.

Blocked on: the compiler issue landing as a published release. Mixing the order is a footgun — a scaffolder release that produces target: "retail" on Linux before the compiler can resolve it will throw exit 3 on every non-Windows machine.

Design

1. New promptDeployTarget() in src/cli/commands.js

Insert between promptLanguage (line 29) and scaffoldCustom (line 32) in src/cli/index.js. The prompt is interactive only when it matters: when bedrock-build reports multiple candidates (see compiler issue §3 "Multiple installs on the same machine"), the scaffolder presents a single-select picker annotated with launcher labels and persists the choice to $XDG_CONFIG_HOME/bedrock-build/config.json / %APPDATA%\bedrock-build\config.json so subsequent npm run deploy runs skip the picker.

Default selection is "Auto-detect local Bedrock (recommended)" on every OS.

? Deploy target: ›
  Auto-detect local Bedrock (recommended)
  Bedrock Dedicated Server
  Custom path
  Skip — I'll configure later

Platform-gated label wording (Linux/macOS list "mcpelauncher / Trinity / BedrockOnLinux" in the Auto-detect label; Windows lists "Minecraft Bedrock launcher / Store / Education").

Follow-up prompts:

• promptBdsPath() — input, non-empty, validate.
• promptCustomPath() — input, non-empty, ~ expanded via os.homedir() at scaffold time. No %VAR% expansion on Windows — no evidence of %VAR% syntax being used in deploy.customPath today, and supporting it would add shell-expansion semantics to the compiler. Users who need it paste the resolved path.
• "Skip" returns target: "custom" with customPath: null. Deploy then throws DeployTargetError exit 3 with an actionable message that enumerates the auto-detected paths the user might have meant.

2. Threading through src/cli/index.js

Call promptDeployTarget() between promptLanguage (line 29) and scaffoldCustom (line 32). Pass the result to scaffoldCustom as a new 4th arg. Drop the "(Windows)" parenthetical from printNextSteps (line 65-66).

3. applyDeployConfig in src/services/customTemplateService.js

Extend scaffoldCustom's signature (src/services/customTemplateService.js:56) to accept the deploy config. Add an applyDeployConfig(targetDir, deployConfig) helper using the existing editJson (line 125) to overwrite bedrock-cli.deploy after substitutePlaceholders (line 77) runs.

When the user picked Auto-detect, write "target": "retail", "customPath": null — same shape as today, no sentinel needed. The cross-platform candidate resolution lives in the compiler.

4. Copy edits

• src/templates/custom/config.json:14-17 — unchanged. Still "target": "retail". The candidate resolver handles the cross-platform logic.
• src/templates/custom/README.md:33-38 — drop "(Bedrock retail on Windows)"; add a 1-liner pointing at bedrock-cli.deploy in config.json.
• README.md:86 — replace "Windows is recommended… (native Mac/Linux retail auto-deploy coming soon)" with a multi-OS + BDS description.
• package.json keywords (create-mc-bedrock-cli/package.json:22) — keep "deploy", no new keywords needed.

5. Bump @keyyard/bedrock-build fallback

src/services/customTemplateService.js:39 — bump { name: '@keyyard/bedrock-build', fallback: '^3.0.0' } to the first 3.x release that ships the platform detection. Separate commit from the prompt/template changes, sequenced after the compiler release is published.

Backward compatibility

• target: "retail" scaffolds continue to behave identically — same shape, same effective config.
• printNextSteps text changes for everyone (copy edit, not behavior change).
• Existing scaffolds generated by 3.0.0 are not retroactively affected.

Test plan

No existing test suite today. Recommended additions if/when one is introduced:

• Fixture-based: render the template with each deploy-target option and assert the generated config.json matches the expected bedrock-cli.deploy shape.
• Unit: mock inquirer.prompt and assert promptDeployTarget returns the right shape per platform (process.platform stub).

Open questions for reviewers

1. User-level config location. $XDG_CONFIG_HOME/bedrock-build/config.json (Linux/macOS) and %APPDATA%\bedrock-build\config.json (Windows). Open to other locations if there's a project convention I'm missing.

Willing to implement

Happy to take this on. The PR split mirrors the compiler issue:

• PR 1: compiler (Keyyard/bedrock-build#1) — schema, paths.ts rewrite, candidate tables, multiple-installs design, tests.
• PR 2: scaffolder (this repo) — new prompt, template edits, copy changes, fallback bump. Depends on PR 1's published release.

Cross-references

• Compiler issue (the blocker): Keyyard/bedrock-build#1.
• BDS install docs: learn.microsoft.com/en-us/minecraft/creator/documents/bedrockserver/getting-started.

[Keyyard]

This sounds good to me. I believe majority are developing on Windows - and local MC Bedrock, which is the reason why default is to the retail version. I have not developed on Mac or Linux before so probably leaving this field for your implementation :)