Replace `@inquirer/prompts` with `@optique/inquirer` in `@fedify/init`

[2chanhaeng]

@fedify/init builds its CLI on Optique (@optique/core, @optique/run), but the interactive prompts in packages/init/src/ask/ still use @inquirer/prompts and inquirer-toggle directly. @optique/inquirer wraps an Optique parser so that an Inquirer.js prompt fires only when no CLI value is provided—exactly the options.x ?? await askX() fallback pattern every fill* function in src/ask/ implements by hand.

Motivation

• The option-parsing layer already uses Optique extensively; moving prompts into the parser removes the hand-written CLI-value/prompt fallback logic in every fill* function.
• inquirer-toggle has had no release since April 2024 (v1.0.1) and is effectively unmaintained; the confirm prompt type covers its use cases.
• Optique and Fedify share a maintainer, so gaps found during migration can be addressed upstream quickly.
• @optique/inquirer (v1.1.1) is published to both JSR and npm, matching the dual-registry dependency policy, and its prompter escape hatch enables TTY-free testing in mise test:init.

Known constraints

• Package manager choices depend on the selected web framework, and KV store/message queue choices depend on the selected package manager. Expressing these declaratively needs an upstream feature (choices derived from other parsed values).
• The re-prompt loops (package manager availability, KV/MQ compatibility) and the non-empty-directory trash confirmation flow in dir.ts run after parsing, so they remain application logic outside the parser.

Please add features for these, @dahlia! 🙏

Scope

Most of the modifications will be in packages/init/, especially packages/init/src/ask/.

[dahlia]

I looked into the Optique-side gaps and opened the following upstream issues:

• Make prompt configuration dependency-aware dahlia/optique#869
  • Register prompted values as dependency sources dahlia/optique#870
  • Allow derived parsers to act as dependency sources dahlia/optique#871
  • Derive prompt configurations from dependencies dahlia/optique#872
• Define validation and retry semantics for prompt adapters dahlia/optique#873

The first group should eventually let @fedify/init express the web framework → package manager → KV store/message queue chain through Optique. Validation for package manager availability and KV/MQ compatibility also seems general enough to support upstream, rather than requiring every application to implement its own adapter-specific retry loop.

I do not plan to turn Optique into a general-purpose interactive workflow engine, though. Optique prompts are fallback value sources within parser evaluation: they should collect missing values while preserving source precedence and consistent dependency, help, and completion semantics. The non-empty-directory flow in dir.ts has a different shape. It branches on filesystem state, asks for confirmation, and coordinates application side effects. Supporting that generically would require Optique to own wizard state, navigation, and side-effect orchestration, which would blur the boundary between parsing and command execution and substantially complicate every prompt adapter.

The intended boundary is therefore that Optique handles missing-value prompts, dependency-aware prompt configuration, and recoverable validation/retry, while @fedify/init keeps the non-empty-directory confirmation flow and similar application-specific workflows.

[dahlia]

I had hoped to include these features in Optique 1.2.0, which is close to release. I prototyped dahlia/optique#870 against the current runtime, but discarded the prototype. It showed that supporting prompted values as dependency sources requires changes to how effectful parsers are scheduled and composed, not just to the prompt adapter; that affects source precedence, wrapper combinators, merge() scoping, and two-pass config loading. I documented the resulting design in dahlia/optique#870 and the related issues, and I do not want to rush those structural changes into 1.2.0.

I am therefore targeting these features for Optique 1.3.0, and 1.2.0 will ship without them. Parts of this migration can proceed before then: the fill* functions whose prompts do not depend on other selections can move to @optique/inquirer now, and the framework → package manager → storage chain can follow once 1.3.0 lands.