#Optique

dahlia/optique Type-safe combinatorial CLI parser for TypeScript. Contribute to dahlia/optique development by creating an account on GitHub.

@hongminhee.org

2 weeks ago

#Optique 1.0.0 preview: runWithConfig() is gone—run() now accepts source contexts. Meta command config gets independent command/option sub-configs. bindConfig() gains config-file metadata for path resolution.

#TypeScript #CLI

2 0 0 0

Original post on hollo.social

2 weeks ago

#Optique 1.0.0 is shaping up, and three API changes are worth knowing about in advance.

* _Runner consolidation_ : `run()` from `@optique/run` now accepts source contexts directly, which makes `runWith()` and `runWithConfig()` redundant for most use cases. `runWithConfig()` is removed […]

1 1 1 0

BotDeLaChatte

@lebotdelachatte.bsky.social

3 weeks ago

Chatoiement de la chatte

Le chatoiement est un phénomène optique qui fait varier la couleur d'un objet selon l'angle de vue, créant un effet scintillant. #Chatoiement #Phenomene #Optique #Couleur #Scintillant

0 0 0 0

A bit of thinking

@baez.link

3 weeks ago

Why Optique? | Optique Discover how Optique brings functional composition to TypeScript CLI development, enabling truly reusable parser components that other libraries can't match through configuration-based approaches.

Interesting to see combinator conditions on #typescript for CLI.

This is something that's hard to do in any CLI library. Easier with typed languages, but still can be complex. Very cool to see with #optique and their approach leveraging the type system. 😎

2 1 0 0

Olivier

@olivierv.bsky.social

1 month ago

‎Google Gemini Meet Gemini, Google’s AI assistant. Get help with writing, planning, brainstorming, and more. Experience the power of generative AI.

Partage d'un #Gems (Google #Gemini ) :

Un assistant à la veille scientifique : gemini.google.com/gem/1xw6KFcT....
Ce Gem's aide à trouver des informations sur les dernières avancées scientifiques (<3mois), avec comme domaines principaux l' #astronomie, l' #astrophysique et l' #optique.

0 0 0 0

Cycle de Krebs

@cycledekrebs.bsky.social

1 month ago

🔍 Observer le monde invisible en 3D change la donne pour les passionnés de sciences. Comment bien choisir son outil d’exploration : www.cycledekrebs.fr/loupe-binocu... #Optique #Découverte

0 0 0 0

Calipia

@calipia.bsky.social

1 month ago

Lunettes Autofocus d’IXI : L’innovation révolutionnaire ou gadget ? Alors que le CES est inondé chaque année par une marée de "smartglasses" et autres dispositifs portables faciaux, l'humble paire de lunettes traditionnelles est restée, somme toute, un monument d'inertie technologique. La dernière avancée notable, si l'on veut être généreux, remonte aux verres progressifs multifocaux des années 1950. Il n'est donc pas surprenant que IXI, un fabricant de lunettes à mise au point automatique, estime qu'il est grand temps de moderniser cet accessoire ancestral.

Les lunettes autofocus d'IXI promettent de réinventer la correction visuelle. Mais entre innovation technique et défis d'intégration, sont-elles vraiment le futur ou juste un gadget de luxe ? #TechInnovation #SmartGlasses #Presbytie #Optique

1 0 0 0

Original post on hollo.social

2 months ago

#Optique 0.9.0 is here!

This release brings #async/await support to #CLI parsers. Now you can validate input against external resources—databases, APIs, Git repositories—directly at parse time, with full #TypeScript type safety.

The new _@optique/git_ package showcases this: validate branch […]

0 3 0 0

Original post on hollo.social

2 months ago

Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with `object()` or `or()`, the combined parser should automatically become async if […]

1 3 0 0

BotDeLaChatte

@lebotdelachatte.bsky.social

2 months ago

Caléidoscope de la chatte

Un caléidoscope est un instrument optique qui crée des motifs colorés en reflétant des formes à travers des miroirs. #caleidoscope #instrument #optique #reflet #couleurs

0 0 0 0

Florence Santrot

@florencesantrot.bsky.social

2 months ago

GoodVision : des lunettes à 1 euro pour changer des vies Dans les pays du Sud, près d’un milliard de personnes vivent avec une malvoyance évitable, faute d’accès à un simple examen de la vue. Depuis plus de dix ans, l’association GoodVision déploie une solu...

Et si 1€ pouvait changer une vie entière ? 👁️✨
L'association GoodVision fabrique des lunettes à 1€ pour ceux qui en ont le plus besoin grâce à une solution low-tech très maline 🌍💡

www.wedemain.fr/sante/goodvi...

#vision #vue #optique #association #goodvision #lunettes

2 0 0 0

Stop writing if statements for your CLI flags If you've built CLI tools, you've written code like this: if (opts.reporter === "junit" && !opts.outputFile) { throw new Error("--output-file is required for junit reporter"); } if (opts.reporter === "html" && !opts.outputFile) { throw new Error("--output-file is required for html reporter"); } if (opts.reporter === "console" && opts.outputFile) { console.warn("--output-file is ignored for console reporter"); } A few months ago, I wrote _Stop writing CLI validation. Parse it right the first time._ about parsing individual option values correctly. But it didn't cover the _relationships_ between options. In the code above, `--output-file` only makes sense when `--reporter` is `junit` or `html`. When it's `console`, the option shouldn't exist at all. We're using TypeScript. We have a powerful type system. And yet, here we are, writing runtime checks that the compiler can't help with. Every time we add a new reporter type, we need to remember to update these checks. Every time we refactor, we hope we didn't miss one. ## The state of TypeScript CLI parsers The old guard—Commander, yargs, minimist—were built before TypeScript became mainstream. They give you bags of strings and leave type safety as an exercise for the reader. But we've made progress. Modern TypeScript-first libraries like cmd-ts and Clipanion (the library powering Yarn Berry) take types seriously: // cmd-ts const app = command({ args: { reporter: option({ type: string, long: 'reporter' }), outputFile: option({ type: string, long: 'output-file' }), }, handler: (args) => { // args.reporter: string // args.outputFile: string }, }); // Clipanion class TestCommand extends Command { reporter = Option.String('--reporter'); outputFile = Option.String('--output-file'); } These libraries infer types for individual options. `--port` is a `number`. `--verbose` is a `boolean`. That's real progress. But here's what they can't do: express that `--output-file` is required _when_ `--reporter` is `junit`, and forbidden _when_ `--reporter` is `console`. The relationship between options isn't captured in the type system. So you end up writing validation code anyway: handler: (args) => { // Both cmd-ts and Clipanion need this if (args.reporter === "junit" && !args.outputFile) { throw new Error("--output-file required for junit"); } // args.outputFile is still string | undefined // TypeScript doesn't know it's definitely string when reporter is "junit" } Rust's clap and Python's Click have `requires` and `conflicts_with` attributes, but those are runtime checks too. They don't change the result type. If the parser configuration knows about option relationships, why doesn't that knowledge show up in the result type? ## Modeling relationships with `conditional()` Optique treats option relationships as a first-class concept. Here's the test reporter scenario: import { conditional, object } from "@optique/core/constructs"; import { option } from "@optique/core/primitives"; import { choice, string } from "@optique/core/valueparser"; import { run } from "@optique/run"; const parser = conditional( option("--reporter", choice(["console", "junit", "html"])), { console: object({}), junit: object({ outputFile: option("--output-file", string()), }), html: object({ outputFile: option("--output-file", string()), openBrowser: option("--open-browser"), }), } ); const [reporter, config] = run(parser); The `conditional()` combinator takes a discriminator option (`--reporter`) and a map of branches. Each branch defines what other options are valid for that discriminator value. TypeScript infers the result type automatically: type Result = | ["console", {}] | ["junit", { outputFile: string }] | ["html", { outputFile: string; openBrowser: boolean }]; When `reporter` is `"junit"`, `outputFile` is `string`—not `string | undefined`. The relationship is encoded in the type. Now your business logic gets real type safety: const [reporter, config] = run(parser); switch (reporter) { case "console": runWithConsoleOutput(); break; case "junit": // TypeScript knows config.outputFile is string writeJUnitReport(config.outputFile); break; case "html": // TypeScript knows config.outputFile and config.openBrowser exist writeHtmlReport(config.outputFile); if (config.openBrowser) openInBrowser(config.outputFile); break; } No validation code. No runtime checks. If you add a new reporter type and forget to handle it in the switch, the compiler tells you. ## A more complex example: database connections Test reporters are a nice example, but let's try something with more variation. Database connection strings: myapp --db=sqlite --file=./data.db myapp --db=postgres --host=localhost --port=5432 --user=admin myapp --db=mysql --host=localhost --port=3306 --user=root --ssl Each database type needs completely different options: * SQLite just needs a file path * PostgreSQL needs host, port, user, and optionally password * MySQL needs host, port, user, and has an SSL flag Here's how you model this: import { conditional, object } from "@optique/core/constructs"; import { withDefault, optional } from "@optique/core/modifiers"; import { option } from "@optique/core/primitives"; import { choice, string, integer } from "@optique/core/valueparser"; const dbParser = conditional( option("--db", choice(["sqlite", "postgres", "mysql"])), { sqlite: object({ file: option("--file", string()), }), postgres: object({ host: option("--host", string()), port: withDefault(option("--port", integer()), 5432), user: option("--user", string()), password: optional(option("--password", string())), }), mysql: object({ host: option("--host", string()), port: withDefault(option("--port", integer()), 3306), user: option("--user", string()), ssl: option("--ssl"), }), } ); The inferred type: type DbConfig = | ["sqlite", { file: string }] | ["postgres", { host: string; port: number; user: string; password?: string }] | ["mysql", { host: string; port: number; user: string; ssl: boolean }]; Notice the details: PostgreSQL defaults to port 5432, MySQL to 3306. PostgreSQL has an optional password, MySQL has an SSL flag. Each database type has exactly the options it needs—no more, no less. With this structure, writing `dbConfig.ssl` when the mode is `sqlite` isn't a runtime error—it's a compile-time impossibility. Try expressing this with `requires_if` attributes. You can't. The relationships are too rich. ## The pattern is everywhere Once you see it, you find this pattern in many CLI tools: **Authentication modes:** const authParser = conditional( option("--auth", choice(["none", "basic", "token", "oauth"])), { none: object({}), basic: object({ username: option("--username", string()), password: option("--password", string()), }), token: object({ token: option("--token", string()), }), oauth: object({ clientId: option("--client-id", string()), clientSecret: option("--client-secret", string()), tokenUrl: option("--token-url", url()), }), } ); **Deployment targets** , **output formats** , **connection protocols** —anywhere you have a mode selector that determines what other options are valid. ## Why `conditional()` exists Optique already has an `or()` combinator for mutually exclusive alternatives. Why do we need `conditional()`? The `or()` combinator distinguishes branches based on **structure** —which options are present. It works well for subcommands like `git commit` vs `git push`, where the arguments differ completely. But in the reporter example, the structure is identical: every branch has a `--reporter` flag. The difference lies in the flag's _value_ , not its presence. // This won't work as intended const parser = or( object({ reporter: option("--reporter", choice(["console"])) }), object({ reporter: option("--reporter", choice(["junit", "html"])), outputFile: option("--output-file", string()) }), ); When you pass `--reporter junit`, `or()` tries to pick a branch based on what options are present. Both branches have `--reporter`, so it can't distinguish them structurally. `conditional()` solves this by reading the discriminator's value first, then selecting the appropriate branch. It bridges the gap between structural parsing and value-based decisions. ## _The structure is the constraint_ Instead of parsing options into a loose type and then validating relationships, define a parser whose structure _is_ the constraint. Traditional approach | Optique approach ---|--- Parse → Validate → Use | Parse (with constraints) → Use Types and validation logic maintained separately | Types reflect the constraints Mismatches found at runtime | Mismatches found at compile time The parser definition becomes the single source of truth. Add a new reporter type? The parser definition changes, the inferred type changes, and the compiler shows you everywhere that needs updating. ## Try it If this resonates with a CLI you're building: * Documentation * Tutorial * `conditional()` reference * GitHub Next time you're about to write an `if` statement checking option relationships, ask: could the parser express this constraint instead? _The structure of your parser is the constraint._ You might not need that validation code at all.

3 months ago

1 1 0 1

CLIのオプション分岐、もうif文は書かなくていい

@hongminhee.org

3 months ago

CLIパーサーの新しい記事を書きました。--reporterの値によって--output-fileが必須になったり禁止になったり…そういう関係、型で表現できたら楽じゃないですか？

#TypeScript #CLI #Optique

1 0 0 0

3 months ago

CLIパーサーの新しい記事を書きました。`--reporter`の値によって`--output-file`が必須になったり禁止になったり…そういう関係、型で表現できたら楽じゃないですか？

https://zenn.dev/hongminhee/articles/201ca6d2e57764

#TypeScript #CLI #Optique

0 2 0 0

Optique 0.8.0: Conditional parsing, pass-through options, and LogTape integration We're excited to announce Optique 0.8.0! This release introduces powerful new features for building sophisticated CLI applications: the `conditional()` combinator for discriminated union patterns, the `passThrough()` parser for wrapper tools, and the new _@optique/logtape_ package for seamless logging configuration. Optique is a type-safe combinatorial CLI parser for TypeScript, providing a functional approach to building command-line interfaces with composable parsers and full type inference. ## New conditional parsing with `conditional()` Ever needed to enable different sets of options based on a discriminator value? The new `conditional()` combinator makes this pattern first-class. It creates discriminated unions where certain options only become valid when a specific discriminator value is selected. import { conditional, object } from "@optique/core/constructs"; import { option } from "@optique/core/primitives"; import { choice, string } from "@optique/core/valueparser"; const parser = conditional( option("--reporter", choice(["console", "junit", "html"])), { console: object({}), junit: object({ outputFile: option("--output-file", string()) }), html: object({ outputFile: option("--output-file", string()) }), } ); // Result type: ["console", {}] | ["junit", { outputFile: string }] | ... Key features: * Explicit discriminator option determines which branch is selected * Tuple result `[discriminator, branchValue]` for clear type narrowing * Optional default branch for when discriminator is not provided * Clear error messages indicating which options are required for each discriminator value The `conditional()` parser provides a more structured alternative to `or()` for discriminated union patterns. Use it when you have an explicit discriminator option that determines which set of options is valid. See the `conditional()` documentation for more details and examples. ## Pass-through options with `passThrough()` Building wrapper CLI tools that need to forward unrecognized options to an underlying tool? The new `passThrough()` parser enables legitimate wrapper/proxy patterns by capturing unknown options without validation errors. import { object } from "@optique/core/constructs"; import { option, passThrough } from "@optique/core/primitives"; const parser = object({ debug: option("--debug"), extra: passThrough(), }); // mycli --debug --foo=bar --baz=qux // → { debug: true, extra: ["--foo=bar", "--baz=qux"] } Key features: * Three capture formats: `"equalsOnly"` (default, safest), `"nextToken"` (captures `--opt val` pairs), and `"greedy"` (captures all remaining tokens) * Lowest priority (−10) ensures explicit parsers always match first * Respects `--` options terminator in `"equalsOnly"` and `"nextToken"` modes * Works seamlessly with `object()`, subcommands, and other combinators This feature is designed for building Docker-like CLIs, build tool wrappers, or any tool that proxies commands to another process. See the `passThrough()` documentation for usage patterns and best practices. ## LogTape logging integration The new _@optique/logtape_ package provides seamless integration with LogTape, enabling you to configure logging through command-line arguments with various parsing strategies. # Deno deno add --jsr @optique/logtape @logtape/logtape # npm npm add @optique/logtape @logtape/logtape Quick start with the `loggingOptions()` preset: import { loggingOptions, createLoggingConfig } from "@optique/logtape"; import { object } from "@optique/core/constructs"; import { parse } from "@optique/core/parser"; import { configure } from "@logtape/logtape"; const parser = object({ logging: loggingOptions({ level: "verbosity" }), }); const args = ["-vv", "--log-output=-"]; const result = parse(parser, args); if (result.success) { const config = await createLoggingConfig(result.value.logging); await configure(config); } The package offers multiple approaches to control log verbosity: * **`verbosity()` parser**: The classic `-v`/`-vv`/`-vvv` pattern where each flag increases verbosity (no flags → `"warning"`, `-v` → `"info"`, `-vv` → `"debug"`, `-vvv` → `"trace"`) * **`debug()` parser**: Simple `--debug`/`-d` flag that toggles between normal and debug levels * **`logLevel()` value parser**: Explicit `--log-level=debug` option for direct level selection * **`logOutput()` parser**: Log output destination with `-` for console or file path for file output See the LogTape integration documentation for complete examples and configuration options. ## Bug fix: negative integers now accepted Fixed an issue where the `integer()` value parser rejected negative integers when using `type: "number"`. The regex pattern has been updated from `/^\d+$/` to `/^-?\d+$/` to correctly handle values like `-42`. Note that `type: "bigint"` already accepted negative integers, so this change brings consistency between the two types. ## Installation # Deno deno add jsr:@optique/core # npm npm add @optique/core # pnpm pnpm add @optique/core # Yarn yarn add @optique/core # Bun bun add @optique/core For the LogTape integration: # Deno deno add --jsr @optique/logtape @logtape/logtape # npm npm add @optique/logtape @logtape/logtape # pnpm pnpm add @optique/logtape @logtape/logtape # Yarn yarn add @optique/logtape @logtape/logtape # Bun bun add @optique/logtape @logtape/logtape ## Looking forward Optique 0.8.0 continues our focus on making CLI development more expressive and type-safe. The `conditional()` combinator brings discriminated union patterns to the forefront, `passThrough()` enables new wrapper tool use cases, and the LogTape integration makes logging configuration a breeze. As always, all new features maintain full backward compatibility—your existing parsers continue to work unchanged. We're grateful to the community for feedback and suggestions. If you have ideas for future improvements or encounter any issues, please let us know through GitHub Issues. For more information about Optique and its features, visit the documentation or check out the full changelog.

3 months ago

1 2 0 1

3 months ago

[4/4]
Une visite riche en questions, en échanges et en perspectives pour ces futurs ingénieurs qui imaginent déjà l’aéronautique et le spatial de demain.

👊 Merci aux équipes du centre de Toulouse pour leur accueil et leur mobilisation.

#ONERA #Recherche #Aéronautique #Optique #Radar

2 0 0 0

3 months ago

[2/3]
Les étudiants ont exploré trois départements ONERA :
➡️DOTA (Département Optique Théorique et Appliquée)
➡️DEMR (Département Electromagnétisme et Radar)👇

#ONERA #Recherche #Aéronautique #Optique #Radar

1 0 1 0

3 months ago

[1/4]
👨‍🎓 Le 26 novembre, le centre ONERA de Toulouse a accueilli un groupe d'étudiants de l’ @isae-supaero.bsky.social
Une matinée dédiée aux échanges et à la découverte de nos missions. 👇

#ONERA #Recherche #Aéronautique #Spatial #Optique #Radar #Toulouse #Innovation #Recrutement

3 1 1 0

3 months ago

[2/3]
Il rejoint le cercle des Optica Fellows pour l’excellence de ses travaux et son leadership en optique non linéaire appliquée à l’ #aéronautique et au #spatial.
Son nom s’ajoute à celui d’Emmanuel Rosencher, Fellow en 2003

#ONERA #Optique

1 0 1 0

Optique 0.7.0: Smarter error messages and validation library integrations We're thrilled to announce Optique 0.7.0, a release focused on developer experience improvements and expanding Optique's ecosystem with validation library integrations. Optique is a type-safe, combinatorial CLI argument parser for TypeScript. Unlike traditional CLI libraries that rely on configuration objects, Optique lets you compose parsers from small, reusable functions—bringing the same functional composition patterns that make Zod powerful to CLI development. If you're new to Optique, check out _Why Optique?_ to learn how this approach unlocks possibilities that configuration-based libraries simply can't match. This release introduces automatic “Did you mean?” suggestions for typos, seamless integration with Zod and Valibot validation libraries, duplicate option name detection for catching configuration bugs early, and context-aware error messages that help users understand exactly what went wrong. ## “Did you mean?”: Automatic typo suggestions We've all been there: you type `--verbos` instead of `--verbose`, and the CLI responds with an unhelpful “unknown option” error. Optique 0.7.0 changes this by automatically suggesting similar options when users make typos: const parser = object({ verbose: option("-v", "--verbose"), version: option("--version"), }); // User types: --verbos (typo) const result = parse(parser, ["--verbos"]); // Error: Unexpected option or argument: --verbos. // // Did you mean one of these? // --verbose // --version The suggestion system uses Levenshtein distance to find similar names, suggesting up to 3 alternatives when the edit distance is within a reasonable threshold. Suggestions work automatically for both option names and subcommand names across all parser types—`option()`, `flag()`, `command()`, `object()`, `or()`, and `longestMatch()`. See the automatic suggestions documentation for more details. ### Customizing suggestions You can customize how suggestions are formatted or disable them entirely through the `errors` option: // Custom suggestion format for option/flag parsers const portOption = option("--port", integer(), { errors: { noMatch: (invalidOption, suggestions) => suggestions.length > 0 ? message`Unknown option ${invalidOption}. Try: ${values(suggestions)}` : message`Unknown option ${invalidOption}.` } }); // Custom suggestion format for combinators const config = object({ host: option("--host", string()), port: option("--port", integer()) }, { errors: { suggestions: (suggestions) => suggestions.length > 0 ? message`Available options: ${values(suggestions)}` : [] } }); ## Zod and Valibot integrations Two new packages join the Optique family, bringing powerful validation capabilities from the TypeScript ecosystem to your CLI parsers. ### @optique/zod The new `@optique/zod` package lets you use Zod schemas directly as value parsers: import { option, object } from "@optique/core"; import { zod } from "@optique/zod"; import { z } from "zod"; const parser = object({ email: option("--email", zod(z.string().email())), port: option("--port", zod(z.coerce.number().int().min(1).max(65535))), format: option("--format", zod(z.enum(["json", "yaml", "xml"]))), }); The package supports both Zod v3.25.0+ and v4.0.0+, with automatic error formatting that integrates seamlessly with Optique's message system. See the Zod integration guide for complete usage examples. ### @optique/valibot For those who prefer a lighter bundle, `@optique/valibot` integrates with Valibot—a validation library with a significantly smaller footprint (~10KB vs Zod's ~52KB): import { option, object } from "@optique/core"; import { valibot } from "@optique/valibot"; import * as v from "valibot"; const parser = object({ email: option("--email", valibot(v.pipe(v.string(), v.email()))), port: option("--port", valibot(v.pipe( v.string(), v.transform(Number), v.integer(), v.minValue(1), v.maxValue(65535) ))), }); Both packages support custom error messages through their respective error handler options (`zodError` and `valibotError`), giving you full control over how validation failures are presented to users. See the Valibot integration guide for complete usage examples. ## Duplicate option name detection A common source of bugs in CLI applications is accidentally using the same option name in multiple places. Previously, this would silently cause ambiguous parsing where the first matching parser consumed the option. Optique 0.7.0 now validates option names at parse time and fails with a clear error message when duplicates are detected: const parser = object({ input: option("-i", "--input", string()), interactive: option("-i", "--interactive"), // Oops! -i is already used }); // Error: Duplicate option name -i found in fields: input, interactive. // Each option name must be unique within a parser combinator. This validation applies to `object()`, `tuple()`, `merge()`, and `group()` combinators. The `or()` combinator continues to allow duplicate option names since its branches are mutually exclusive. See the duplicate detection documentation for more details. If you have a legitimate use case for duplicate option names, you can opt out with `allowDuplicates: true`: const parser = object({ input: option("-i", "--input", string()), interactive: option("-i", "--interactive"), }, { allowDuplicates: true }); ## Context-aware error messages Error messages from combinators are now smarter about what they report. Instead of generic "No matching option or command found" messages, Optique now analyzes what the parser expects and provides specific feedback: // When only arguments are expected const parser1 = or(argument(string()), argument(integer())); // Error: Missing required argument. // When only commands are expected const parser2 = or(command("add", addParser), command("remove", removeParser)); // Error: No matching command found. // When both options and arguments are expected const parser3 = object({ port: option("--port", integer()), file: argument(string()), }); // Error: No matching option or argument found. ### Dynamic error messages with `NoMatchContext` For applications that need internationalization or context-specific messaging, the `errors.noMatch` option now accepts a function that receives a `NoMatchContext` object: const parser = or( command("add", addParser), command("remove", removeParser), { errors: { noMatch: ({ hasOptions, hasCommands, hasArguments }) => { if (hasCommands && !hasOptions && !hasArguments) { return message`일치하는 명령을 찾을 수 없습니다.`; // Korean } return message`잘못된 입력입니다.`; } } } ); ## Shell completion naming conventions The `run()` function now supports configuring whether shell completions use singular or plural naming conventions: run(parser, { completion: { name: "plural", // Uses "completions" and "--completions" } }); // Or for singular only run(parser, { completion: { name: "singular", // Uses "completion" and "--completion" } }); The default `"both"` accepts either form, maintaining backward compatibility while letting you enforce a consistent style in your CLI. ## Additional improvements * **Line break handling** : `formatMessage()` now distinguishes between soft breaks (single `\n`, converted to spaces) and hard breaks (double `\n\n`, creating paragraph separations), improving multi-line error message formatting. * **New utility functions** : Added `extractOptionNames()` and `extractArgumentMetavars()` to the `@optique/core/usage` module for programmatic access to parser metadata. ## Installation deno add --jsr @optique/core @optique/run npm add @optique/core @optique/run pnpm add @optique/core @optique/run yarn add @optique/core @optique/run bun add @optique/core @optique/run For validation library integrations: # Zod integration deno add jsr:@optique/zod # Deno npm add @optique/zod # npm/pnpm/yarn/bun # Valibot integration deno add jsr:@optique/valibot # Deno npm add @optique/valibot # npm/pnpm/yarn/bun ## Looking forward This release represents our commitment to making CLI development in TypeScript as smooth as possible. The “Did you mean?” suggestions and validation library integrations were among the most requested features, and we're excited to see how they improve your CLI applications. For detailed documentation and examples, visit the Optique documentation. We welcome your feedback and contributions on GitHub!

3 months ago

2 6 0 1

Audrey Linkenheld

@audreylinkenheld.bsky.social

3 months ago

#optique
Merci à la FNOF et son président Hugues Verdier-Davioud d’avoir choisi #Lille pour son congrès 2025.

L’occasion de parler protection des données de #santé et d’aborder les attentes des opticiens en lien avec le #PLFSS2026 ou le projet de loi #Fraudes.

0 0 0 0

feature or docs request: "extra options" parser · Issue #35 · dahlia/optique First of all, thank you for this excellent project. I'm still getting familiar with it, but it's been a fun time so far. I'm writing a wrapper around another tool. The wrapper has some extra option...

4 months ago

Interesting design question for #Optique (a type-safe #CLI parser for #TypeScript): how should it handle unrecognized options in wrapper/proxy tools? Proposed three modes but wondering if the complexity is worth it. Thoughts?

https://github.com/dahlia/optique/issues/35

2 2 0 0

Cycle de Krebs

@cycledekrebs.bsky.social

5 months ago

🔍 Choisir une loupe binoculaire adaptée évite frustration et perte de temps. Professionnels et amateurs : voici les critères à ne pas négliger : www.cycledekrebs.fr/loupe-binocu...
#Optique #Recherche

0 0 0 0

Olivier

@olivierv.bsky.social

5 months ago

[Fil 🧵 #Sciences #optique ]
NB : l'ensemble du texte est disponible à la page suivante : docs.google.com/document/d/1...

(1/11)

0 1 1 1