← Back to issue list

Always report error messages for incorrect usage

View original Github issue

Metadata

Project
craft-cli
Number
#262
Type
issue
State
open
Author
mattculler
Labels
—
Created
Updated
Closed
—

Current evaluation

No-command invocations still display general help instead of a specific “no command specified” error; the behavior remains in the current Dispatcher.

Suggested action: keep open

Reason: The current empty-argument branch still raises ArgumentParsingError with the full general help when no default command exists, confirming the reported behavior remains unresolved. The exact reproducer and intended outcome make this a small, testable change; commit 7b630a9 (#422) added explicit default-command errors but did not address this no-default-command branch.

Evaluated by: mr-cal-bot

Impact: 28 Quick Win: 21 Complexity: 20 Confidence: 95 Actionability: 92

Issue body

### What needs to get done Most CLI usage errors output exactly what I would expect - a basic usage line, suggestion to consult `-h`, and an error message: ``` $ corncraft foo Usage: corncraft [options] command [args]... Try 'corncraft -h' for help. Error: no such command 'foo' $ corncraft pack --foo Usage: corncraft [options] command [args]... Try 'corncraft pack -h' for help. Error: unrecognized arguments: --foo ``` But passing no command at all will instead output the help text, with no explanation. (It does return nonzero.) The "no command specified" case should get its own message. In my view, even a generic error message would be better than the help text, which is annoying - I would argue that we should also change the case where help output is displayed in response to a generic error. ### Why it needs to get done This will likely be confusing for new users.

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 28
Quick Win: 21
Complexity: 20
Confidence: 95
Actionability: 92
keep open No-command invocations still display general help instead of a specific “no command specified” error; the behavior remains in the current Dispatcher.
qwen/qwen3.6-35b-a3b
Impact: 35
Quick Win: 21
Complexity: 25
Confidence: 75
Actionability: 80
needs triage Request to show an explicit error message instead of help text when no command is specified in CLI usage.
qwen/qwen3.8-27b
Impact: 40
Quick Win: 28
Staleness: 72
Complexity: 30
Confidence: 75
Support Request: 5
needs triage CLI prints full help text instead of an error when invoked with no command; partially addressed by #422 which errors when a default command is disallowed, but the no-default-command case still dumps help text. Unlabelled, no maintainer response.
qwen/qwen3.6-35b-a3b
Staleness: 90
Complexity: 15
Confidence: 85
Support Request: 10
close stale CLI displays help text instead of an error when run without a command. Issue lacks labels, assignee, and maintainer engagement, remaining inactive for over 16 months.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 15
Confidence: 80
Support Request: 0
needs triage CLI displays help text instead of an error when invoked without a command. The issue remains unlabelled and unassessed by maintainers after over two years.

Update history

No update history recorded yet.

Related work

  • Related To: craft-cli#422 (confidence 82%)

    Commit 7b630a9 improved errors involving default commands, but the no-default-command path still emits only help.

Related issues

No related issues found above the similarity threshold.