fix: unbreak the CLI on Windows and make create scriptable - #9
Conversation
Three bugs found while exercising the CLI end to end against production. 1. Every command crashed on Windows. The UI prints emoji and box-drawing characters, but the Windows console defaults to cp1252, which cannot encode them. `ufazien --help` died with UnicodeEncodeError before printing anything, and so did any other command that reached the banner. stdout/stderr are now reconfigured to UTF-8 with errors="replace", so unencodable output degrades instead of aborting. 2. `create` hung forever when not attached to a terminal. It prompted for a description and for "Create project structure?" unconditionally, even when every flag was supplied, so scripted and CI use blocked on a read that never returned. Prompts are now skipped when stdin is not a TTY or --yes is passed, and the missing pieces are supplied by new --description, --build-folder and --yes flags. Required values that cannot be defaulted fail fast with a message naming the flag to pass. 3. Aborting `create` orphaned the website. .ufazien.json was written at the very end, after the scaffolding prompts, while the website and its database were created well before them. Answering "no", pressing Ctrl-C, or any error in between left the resources existing server-side with nothing local recording their ids: `deploy` could not find the site, and re-running `create` silently provisioned a duplicate. The config is now saved as soon as the remote resources exist. Also adds --no-structure. Scaffolding overwrites files like index.html, which is fine when a human confirms it but destructive in a scripted run against an existing project. Both packages are affected identically and are fixed in parallel; the encoding fix is Python-only since Node does not have that failure mode. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 52 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe JavaScript and Python ChangesCreate workflow
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@ufazien-cli-py/src/ufazien/cli.py`:
- Around line 130-131: Resolve the Ruff FA100 diagnostics in the CLI option
declarations by making Optional available before the annotations in the module,
either by adding the typing import or enabling postponed annotations with the
future directive. Keep the existing description and build_folder_opt annotations
unchanged.
- Around line 311-328: Update the create flow to persist configuration
immediately after create_website returns, including the website ID, then update
and save database_id as soon as create_database completes and before readiness
polling begins. Ensure the existing later save does not remain the sole
persistence point, while preserving the current configuration fields and
build_folder handling.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: c65f6433-225f-4c27-803f-cf33b723498a
📒 Files selected for processing (2)
ufazien-cli-js/src/cli.tsufazien-cli-py/src/ufazien/cli.py
Found while exercising the CLI end to end against production (create + deploy for static, PHP+database, and build projects). All three site types deploy correctly; these are the defects hit along the way.
1. Every command crashed on Windows
The UI prints emoji and box-drawing characters, but the Windows console defaults to cp1252, which cannot encode them:
--helpnever printed at all. Fixed by reconfiguring stdout/stderr to UTF-8 witherrors="replace", so unencodable output degrades instead of aborting. Python only — Node does not have this failure mode.2.
createhung forever without a terminalIt prompted for a description and for "Create project structure?" unconditionally, even when every flag was supplied, so any scripted or CI use blocked on a read that never returned.
Prompts are now skipped when stdin is not a TTY or
--yesis passed. New flags supply what the prompts used to:--description,--build-folder,--yes. Values that cannot be defaulted fail fast naming the flag to pass, instead of hanging.3. Aborting
createorphaned the website.ufazien.jsonwas written at the very end, after the scaffolding prompts — but the website and its database were created well before them. Answering "no", pressing Ctrl-C, or any error in between left both existing server-side with nothing local recording their ids:deploycould not find the site, and re-runningcreatesilently provisioned a duplicate.I hit this on the first run and had to reconstruct
.ufazien.jsonby hand. The config is now saved as soon as the remote resources exist.Also:
--no-structureScaffolding overwrites files like
index.html. Fine when a human confirms it, destructive in a scripted run against an existing project.Verification
ufazien --helpon Windows without any encoding workaround ✅create --yes+deploywith no TTY, end to end, site live ✅--no-structureleaves an existingindex.htmluntouched ✅createwith no name and no TTY fails immediately with guidance, rather than hanging ✅tsc --noEmitclean; both packages build (npm run build,python -m build) ✅Note on releasing
No version bump here, since publishing is triggered by pushing a
v*tag (which creates the Release that the PyPI/npm workflows listen for), not by merging tomain. Bump and tag when you want 0.3.2 out.Summary by CodeRabbit
--yesand automatic non-TTY support.