@optique/core 1.2.0-dev.2298 → 1.2.0-dev.2302

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -40,8 +40,11 @@ Core rules
40
40
  - Use `message` from *@optique/core/message* for descriptions, help text, and
41
41
  custom errors. Prefer semantic message helpers such as `optionName()` and
42
42
  `metavar()` over string concatenation when naming CLI elements.
43
- - Use value parsers such as `integer()`, `choice()`, `url()`, and `uuid()`
44
- instead of validating raw strings after parsing. Use `path()` from
43
+ - Use value parsers such as `integer()`, `choice()`, `biject()`, `url()`,
44
+ and `uuid()` instead of validating raw strings after parsing. Use
45
+ `biject()` for one-to-one string-to-value choices, and use `transform()`
46
+ when an existing value parser describes the accepted CLI spelling but your
47
+ app needs a different result type. Use `path()` from
45
48
  `@optique/run/valueparser` for file-system paths. Write a custom
46
49
  `{ mode, metavar, parse, format }` value parser only when the catalog does
47
50
  not cover the domain.
@@ -55,6 +58,8 @@ Core rules
55
58
  apps. Do not hand-write completion scripts from parser metadata.
56
59
  - Use `showUsage: false` in runner options when full help should show the
57
60
  brief and command or option sections without the `Usage:` synopsis.
61
+ For deeply nested command trees, add `commandList: "top-level"` when root
62
+ help should list only first-level command groups.
58
63
 
59
64
 
60
65
  Canonical app shape
@@ -136,9 +141,32 @@ if (result.success) {
136
141
  Custom value parsers
137
142
  --------------------
138
143
 
139
- Prefer the built-in catalog first. When a custom domain is needed, keep the
140
- validation in a value parser so help, errors, defaults, prompts, and completion
141
- all see the same typed value.
144
+ Prefer the built-in catalog first. If a one-to-one dictionary can describe the
145
+ input tokens and domain values, use `biject()`. If an existing parser already
146
+ accepts the right input syntax, wrap it with `transform()` before writing a
147
+ custom parser:
148
+
149
+ ~~~~ typescript
150
+ import { biject, choice, transform } from "@optique/core/valueparser";
151
+
152
+ const exitCode = biject({
153
+ ok: 0,
154
+ warning: 1,
155
+ error: 2,
156
+ });
157
+
158
+ const logLevel = transform(choice(["debug", "info", "warn", "error"] as const), {
159
+ map(value) {
160
+ return value.toUpperCase() as "DEBUG" | "INFO" | "WARN" | "ERROR";
161
+ },
162
+ unmap(value) {
163
+ return value.toLowerCase() as "debug" | "info" | "warn" | "error";
164
+ },
165
+ });
166
+ ~~~~
167
+
168
+ When a custom domain is needed, keep the validation in a value parser so help,
169
+ errors, defaults, prompts, and completion all see the same typed value.
142
170
 
143
171
  ~~~~ typescript
144
172
  import { message } from "@optique/core/message";