Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

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.

  • hongminhee@hollo.socialundefined hongminhee@hollo.social shared this topic on

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 0 Votes
    2 Posts
    11 Views
    @tommi @xpub WHAT WILL I GET IF I WIN
  • 0 Votes
    1 Posts
    10 Views
    We've all been there. You start a quick TypeScript CLI with process.argv.slice(2), add a couple of options, and before you know it you're drowning in if/else blocks and parseInt calls. It works, until it doesn't. In this guide, we'll move from manual argument parsing to a fully type-safe CLI with subcommands, mutually exclusive options, and shell completion. The naïve approach: parsing process.argv Let's start with the most basic approach. Say we want a greeting program that takes a name and optionally repeats the greeting: // greet.ts const args = process.argv.slice(2); let name: string | undefined; let count = 1; for (let i = 0; i < args.length; i++) { if (args[i] === "--name" || args[i] === "-n") { name = args[++i]; } else if (args[i] === "--count" || args[i] === "-c") { count = parseInt(args[++i], 10); } } if (!name) { console.error("Error: --name is required"); process.exit(1); } for (let i = 0; i < count; i++) { console.log(`Hello, ${name}!`); } Run node greet.js --name Alice --count 3 and you'll get three greetings. But this approach is fragile. count could be NaN if someone passes --count foo, and we'd silently proceed. There's no help text. If someone passes --name without a value, we'd read the next option as the name. And the boilerplate grows fast with each new option. The traditional libraries You've probably heard of Commander.js and Yargs. They've been around for years and solve the basic problems: // With Commander.js import { program } from "commander"; program .requiredOption("-n, --name <n>", "Name to greet") .option("-c, --count <number>", "Number of times to greet", "1") .parse(); const opts = program.opts(); These libraries handle help text, option parsing, and basic validation. But they were designed before TypeScript became mainstream, and the type safety is bolted on rather than built in. The real problem shows up when you need mutually exclusive options. Say your CLI works either in "server mode" (with --port and --host) or "client mode" (with --url). With these libraries, you end up with a config object where all options are potentially present, and you're left writing runtime checks to ensure the user didn't mix incompatible flags. TypeScript can't help you because the types don't reflect the actual constraints. Enter Optique Optique takes a different approach. Instead of configuring options declaratively, you build parsers by composing smaller parsers together. The types flow naturally from this composition, so TypeScript always knows exactly what shape your parsed result will have. Optique works across JavaScript runtimes: Node.js, Deno, and Bun are all supported. The core parsing logic has no runtime-specific dependencies, so you can even use it in browsers if you need to parse CLI-like arguments in a web context. Let's rebuild our greeting program: import { object } from "@optique/core/constructs"; import { option } from "@optique/core/primitives"; import { integer, string } from "@optique/core/valueparser"; import { withDefault } from "@optique/core/modifiers"; import { run } from "@optique/run"; const parser = object({ name: option("-n", "--name", string()), count: withDefault(option("-c", "--count", integer({ min: 1 })), 1), }); const config = run(parser); // config is typed as { name: string; count: number } for (let i = 0; i < config.count; i++) { console.log(`Hello, ${config.name}!`); } Types are inferred automatically. config.name is string, not string | undefined. config.count is number, guaranteed to be at least 1. Validation is built in: integer({ min: 1 }) rejects non-integers and values below 1 with clear error messages. Help text is generated automatically, and the run() function handles errors and exits with appropriate codes. Install it with your package manager of choice: npm add @optique/core @optique/run # or: pnpm add, yarn add, bun add, deno add jsr:@optique/core jsr:@optique/run Building up: a file converter Let's build something more realistic: a file converter that reads from an input file, converts to a specified format, and writes to an output file. import { object } from "@optique/core/constructs"; import { optional, withDefault } from "@optique/core/modifiers"; import { argument, option } from "@optique/core/primitives"; import { choice, string } from "@optique/core/valueparser"; import { run } from "@optique/run"; const parser = object({ input: argument(string({ metavar: "INPUT" })), output: option("-o", "--output", string({ metavar: "FILE" })), format: withDefault( option("-f", "--format", choice(["json", "yaml", "toml"])), "json" ), pretty: option("-p", "--pretty"), verbose: option("-v", "--verbose"), }); const config = run(parser, { help: "both", version: { mode: "both", value: "1.0.0" }, }); // config.input: string // config.output: string // config.format: "json" | "yaml" | "toml" // config.pretty: boolean // config.verbose: boolean The type of config.format isn't just string. It's the union "json" | "yaml" | "toml". TypeScript will catch typos like config.format === "josn" at compile time. The choice() parser is useful for any option with a fixed set of valid values: log levels, output formats, environment names, and so on. You get both runtime validation (invalid values are rejected with helpful error messages) and compile-time checking (TypeScript knows the exact set of possible values). Mutually exclusive options Now let's tackle the case that trips up most CLI libraries: mutually exclusive options. Say our tool can either run as a server or connect as a client, but not both: import { object, or } from "@optique/core/constructs"; import { withDefault } from "@optique/core/modifiers"; import { argument, constant, option } from "@optique/core/primitives"; import { integer, string, url } from "@optique/core/valueparser"; import { run } from "@optique/run"; const parser = or( // Server mode object({ mode: constant("server"), port: option("-p", "--port", integer({ min: 1, max: 65535 })), host: withDefault(option("-h", "--host", string()), "0.0.0.0"), }), // Client mode object({ mode: constant("client"), url: argument(url()), }), ); const config = run(parser); The or() combinator tries each alternative in order. The first one that successfully parses wins. The constant() parser adds a literal value to the result without consuming any input, which serves as a discriminator. TypeScript infers a discriminated union: type Config = | { mode: "server"; port: number; host: string } | { mode: "client"; url: URL }; Now you can write type-safe code that handles each mode: if (config.mode === "server") { console.log(`Starting server on ${config.host}:${config.port}`); } else { console.log(`Connecting to ${config.url.hostname}`); } Try accessing config.url in the server branch. TypeScript won't let you. The compiler knows that when mode is "server", only port and host exist. This is the key difference from configuration-based libraries. With Commander or Yargs, you'd get a type like { port?: number; host?: string; url?: string } and have to check at runtime which combination of fields is actually present. With Optique, the types match the actual constraints of your CLI. Subcommands For larger tools, you'll want subcommands. Optique handles this with the command() parser: import { object, or } from "@optique/core/constructs"; import { optional } from "@optique/core/modifiers"; import { argument, command, constant, option } from "@optique/core/primitives"; import { string } from "@optique/core/valueparser"; import { run } from "@optique/run"; const parser = or( command("add", object({ action: constant("add"), key: argument(string({ metavar: "KEY" })), value: argument(string({ metavar: "VALUE" })), })), command("remove", object({ action: constant("remove"), key: argument(string({ metavar: "KEY" })), })), command("list", object({ action: constant("list"), pattern: optional(option("-p", "--pattern", string())), })), ); const result = run(parser, { help: "both" }); switch (result.action) { case "add": console.log(`Adding ${result.key}=${result.value}`); break; case "remove": console.log(`Removing ${result.key}`); break; case "list": console.log(`Listing${result.pattern ? ` (filter: ${result.pattern})` : ""}`); break; } Each subcommand gets its own help text. Run myapp add --help and you'll see only the options relevant to add. Run myapp --help and you'll see a summary of all available commands. The pattern here is the same as mutually exclusive options: or() to combine alternatives, constant() to add a discriminator. This consistency is one of Optique's strengths. Once you understand the basic combinators, you can build arbitrarily complex CLI structures by composing them. Shell completion Optique has built-in shell completion for Bash, zsh, fish, PowerShell, and Nushell. Enable it by passing completion: "both" to run(): const config = run(parser, { help: "both", version: { mode: "both", value: "1.0.0" }, completion: "both", }); Users can then generate completion scripts: $ myapp --completion bash >> ~/.bashrc $ myapp --completion zsh >> ~/.zshrc $ myapp --completion fish > ~/.config/fish/completions/myapp.fish The completions are context-aware. They know about your subcommands, option values, and choice() alternatives. Type myapp --format <TAB> and you'll see json, yaml, toml as suggestions. Type myapp a<TAB> and it'll complete to myapp add. Completion support is often an afterthought in CLI tools, but it makes a real difference in user experience. With Optique, you get it essentially for free. Integrating with validation libraries Already using Zod for validation in your project? The @optique/zod package lets you reuse those schemas as CLI value parsers: import { z } from "zod"; import { zod } from "@optique/zod"; import { option } from "@optique/core/primitives"; const email = option("--email", zod(z.string().email())); const port = option("--port", zod(z.coerce.number().int().min(1).max(65535))); Your existing validation logic just works. The Zod error messages are passed through to the user, so you get the same helpful feedback you're used to. Prefer Valibot? The @optique/valibot package works the same way: import * as v from "valibot"; import { valibot } from "@optique/valibot"; import { option } from "@optique/core/primitives"; const email = option("--email", valibot(v.pipe(v.string(), v.email()))); Valibot's bundle size is significantly smaller than Zod's (~10KB vs ~52KB), which can matter for CLI tools where startup time is noticeable. Tips A few things I've learned building CLIs with Optique: Start simple. Begin with object() and basic options. Add or() for mutually exclusive groups only when you need them. It's easy to over-engineer CLI parsers. Use descriptive metavars. Instead of string(), write string({ metavar: "FILE" }) or string({ metavar: "URL" }). The metavar appears in help text and error messages, so it's worth the extra few characters. Leverage withDefault(). It's better than making options optional and checking for undefined everywhere. Your code becomes cleaner when you can assume values are always present. Test your parser. Optique's core parsing functions work without process.argv, so you can unit test your parser logic: import { parse } from "@optique/core/parser"; const result = parse(parser, ["--name", "Alice", "--count", "3"]); if (result.success) { assert.equal(result.value.name, "Alice"); assert.equal(result.value.count, 3); } This is especially valuable for complex parsers with many edge cases. Going further We've covered the fundamentals, but Optique has more to offer: Async value parsers for validating against external sources, like checking if a Git branch exists or if a URL is reachable Path validation with path() for checking file existence, directory structure, and file extensions Custom value parsers for domain-specific types (though Zod/Valibot integration is usually easier) Reusable option groups with merge() for sharing common options across subcommands The @optique/temporal package for parsing dates and times using the Temporal API Check out the documentation for the full picture. The tutorial walks through the concepts in more depth, and the cookbook has patterns for common scenarios. That's it Building CLIs in TypeScript doesn't have to mean fighting with types or writing endless runtime validation. Optique lets you express constraints in a way that TypeScript actually understands, so the compiler catches mistakes before they reach production. The source is on GitHub, and packages are available on both npm and JSR. Questions or feedback? Find me on the fediverse or open an issue on the GitHub repo.
  • 0 Votes
    1 Posts
    9 Views
    CVSS 10.0 critical severity vulnerablility affecting server-side use of React.js, tracked as: CVE-2025-55182 in React.js CVE-2025-66478 specifically for the Next.js framework https://react2shell.com #infosec #javascript #react
  • 0 Votes
    1 Posts
    12 Views
    Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374). This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!