Optique just crossed 600 GitHub stars!

For those unfamiliar: #Optique is a #CLI parsing library for #TypeScript that takes a parser combinator approach, inspired by Haskell's optparse-applicative. The core idea is “parse, don't validate”—you express constraints like mutually exclusive options or dependent flags through types, and TypeScript infers the rest automatically. No runtime validation boilerplate needed.

It started as something I built out of frustration while working on Fedify, an ActivityPub framework, when no existing CLI library could express the constraints I needed in a type-safe way. Apparently I wasn't the only one who felt that way.

Thank you all for the support.

https://github.com/dahlia/optique

Plongez dans la lorgnette des micromondes : explication détaillée du module optique et du choix caméra/objectifs (même montage que l’Armorscope) 🦠🔬 Clair, pédagogique et parfait pour maker·s et curieux·ses qui veulent savoir comment on « scrolle » le plancton. #science #microscopie #plancton #optique #DIY #éducation #PeerTube #French
https://peertube.guillaumeleguen.xyz/videos/watch/5d150ad5-d731-4dd9-bbb2-d03419742367
La lorgnette des micromondes en détail - Le module optique

PeerTube
🔍 Observer des échantillons en relief demande un outil adapté. Une loupe binoculaire offre une vision tridimensionnelle idéale pour les détails infimes. Comment bien la choisir selon vos besoins ? Le guide complet pour éviter les erreurs : https://www.cycledekrebs.fr/loupe-binoculaire/ #Optique #Laboratoire

Super explication de l'astigmatisme !
Clair et didactique !

C'est ptet pour ça, en plus de ma myopie de bourrin (-7) que les fonds sombres me dérangent toujours un peu…

https://linuxfr.org/users/jben/journaux/je-hais-les-themes-sombres-et-je-peux-l-expliquer

#astigmatisme #optique

Je hais les thèmes sombres, et je peux l'expliquer - LinuxFr.org

Je hais les thèmes sombres, et je peux l'expliquer

#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 outright—no deprecation, since we have a major version to absorb the break. For the typical CLI, run() is now the single entry point.

  • Meta command config redesign: help, version, and completion in RunOptions no longer use mode: "command" | "option" | "both". Each now takes independent command and option sub-configs, which makes it possible to give --help a -h alias, hide a meta command from usage lines while keeping it in the help listing, or group the command and option forms differently. String shorthands (help: "both", version: "1.2.3", etc.) still work exactly as before.

  • Config-file-relative paths: bindConfig()'s key callback now receives config file metadata as a second argument—configDir and configPath—so you can resolve paths relative to the config file's location rather than the working directory. This matches how tools like the TypeScript compiler handle outDir and similar path options.

More details on the 1.0.0 milestone.

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. 😎

https://optique.dev/why

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.

🔍 L’observation fine d’échantillons nécessite un outil adapté à la vision binoculaire. Ce type de loupe offre une précision inégalée pour analyser des détails infimes. Idéal pour les passionnés de nature ou de sciences, son choix dépend de critères précis. Trouvez le modèle qui répond à vos besoins : https://www.cycledekrebs.fr/loupe-binoculaire/ #Optique #Observation
🔍 Observer des détails infiniment petits demande un outil adapté. La loupe binoculaire offre une vision 3D idéale pour enfants et passionnés. Choisir le bon modèle change votre expérience d’exploration. Guide complet pour faire le bon choix : https://www.cycledekrebs.fr/loupe-binoculaire/ #Optique #Découverte

Your CLI's completion should know what options you've already typed

https://hackers.pub/@hongminhee/2026/optique-context-aware-cli-completion

Your CLI's completion should know what options you've already typed

Consider Git's -C option: git -C /path/to/repo checkout <TAB> When you hit Tab, Git completes branch names from /path/to/repo, not yourcurrent directory. The completion is context-aware—it depends on the value ofanother option. Most CLI parsers can't do this. They treat each option in isolation, socompletion for --branch has no way of knowing the --repo value. You end upwith two unpleasant choices: either show completions for all possiblebranches across all repositories (useless), or give up on completion entirelyfor these options. Optique 0.10.0 introduces a dependency system that solves this problem whilepreserving full type safety. Static dependencies with or() Optique already handles certain kinds of dependent options via the or()combinator: import { flag, object, option, or, string } from "@optique/core";const outputOptions = or( object({ json: flag("--json"), pretty: flag("--pretty"), }), object({ csv: flag("--csv"), delimiter: option("--delimiter", string()), }),); TypeScript knows that if json is true, you'll have a pretty field, and ifcsv is true, you'll have a delimiter field. The parser enforces this atruntime, and shell completion will suggest --pretty only when --json ispresent. This works well when the valid combinations are known at definition time. Butit can't handle cases where valid values depend on runtime input—likebranch names that vary by repository. Runtime dependencies Common scenarios include: A deployment CLI where --environment affects which services are available A database tool where --connection affects which tables can be completed A cloud CLI where --project affects which resources are shown In each case, you can't know the valid values until you know what the usertyped for the dependency option. Optique 0.10.0 introduces dependency() andderive() to handle exactly this. The dependency system The core idea is simple: mark one option as a dependency source, then createderived parsers that use its value. import { choice, dependency, message, object, option, string,} from "@optique/core";function getRefsFromRepo(repoPath: string): string[] { // In real code, this would read from the Git repository return ["main", "develop", "feature/login"];}// Mark as a dependency sourceconst repoParser = dependency(string());// Create a derived parserconst refParser = repoParser.derive({ metavar: "REF", factory: (repoPath) => { const refs = getRefsFromRepo(repoPath); return choice(refs); }, defaultValue: () => ".",});const parser = object({ repo: option("--repo", repoParser, { description: message`Path to the repository`, }), ref: option("--ref", refParser, { description: message`Git reference`, }),}); The factory function is where the dependency gets resolved. It receives theactual value the user provided for --repo and returns a parser that validatesagainst refs from that specific repository. Under the hood, Optique uses a three-phase parsing strategy: Parse all options in a first pass, collecting dependency values Call factory functions with the collected values to create concrete parsers Re-parse derived options using those dynamically created parsers This means both validation and completion work correctly—if the user hasalready typed --repo /some/path, the --ref completion will show refs fromthat path. Repository-aware completion with @optique/git The @optique/git package provides async value parsers that read from Gitrepositories. Combined with the dependency system, you can build CLIs withrepository-aware completion: import { command, dependency, message, object, option, string,} from "@optique/core";import { gitBranch } from "@optique/git";const repoParser = dependency(string());const branchParser = repoParser.deriveAsync({ metavar: "BRANCH", factory: (repoPath) => gitBranch({ dir: repoPath }), defaultValue: () => ".",});const checkout = command( "checkout", object({ repo: option("--repo", repoParser, { description: message`Path to the repository`, }), branch: option("--branch", branchParser, { description: message`Branch to checkout`, }), }),); Now when you type my-cli checkout --repo /path/to/project --branch <TAB>, thecompletion will show branches from /path/to/project. The defaultValue of"." means that if --repo isn't specified, it falls back to the currentdirectory. Multiple dependencies Sometimes a parser needs values from multiple options. The deriveFrom()function handles this: import { choice, dependency, deriveFrom, message, object, option,} from "@optique/core";function getAvailableServices(env: string, region: string): string[] { return [`${env}-api-${region}`, `${env}-web-${region}`];}const envParser = dependency(choice(["dev", "staging", "prod"] as const));const regionParser = dependency(choice(["us-east", "eu-west"] as const));const serviceParser = deriveFrom({ dependencies: [envParser, regionParser] as const, metavar: "SERVICE", factory: (env, region) => { const services = getAvailableServices(env, region); return choice(services); }, defaultValues: () => ["dev", "us-east"] as const,});const parser = object({ env: option("--env", envParser, { description: message`Deployment environment`, }), region: option("--region", regionParser, { description: message`Cloud region`, }), service: option("--service", serviceParser, { description: message`Service to deploy`, }),}); The factory receives values in the same order as the dependency array. Ifsome dependencies aren't provided, Optique uses the defaultValues. Async support Real-world dependency resolution often involves I/O—reading from Gitrepositories, querying APIs, accessing databases. Optique provides asyncvariants for these cases: import { dependency, string } from "@optique/core";import { gitBranch } from "@optique/git";const repoParser = dependency(string());const branchParser = repoParser.deriveAsync({ metavar: "BRANCH", factory: (repoPath) => gitBranch({ dir: repoPath }), defaultValue: () => ".",}); The @optique/git package uses isomorphic-git under the hood, sogitBranch(), gitTag(), and gitRef() all work in both Node.js and Deno. There's also deriveSync() for when you need to be explicit about synchronousbehavior, and deriveFromAsync() for multiple async dependencies. Wrapping up The dependency system lets you build CLIs where options are aware of eachother—not just for validation, but for shell completion too. You get typesafety throughout: TypeScript knows the relationship between your dependencysources and derived parsers, and invalid combinations are caught at compiletime. This is particularly useful for tools that interact with external systems wherethe set of valid values isn't known until runtime. Git repositories, cloudproviders, databases, container registries—anywhere the completion choicesdepend on context the user has already provided. This feature will be available in Optique 0.10.0. To try the pre-release: deno add jsr:@optique/[email protected] Or with npm: npm install @optique/[email protected] See the documentation for more details.

Hackers' Pub