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

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 <kbd>Tab</kbd>, Git completes branch names from /path/to/repo, not your
    current directory. The completion is context-aware—it depends on the value of
    another option.

    Most CLI parsers can't do this. They treat each option in isolation, so
    completion for --branch has no way of knowing the --repo value. You end up
    with two unpleasant choices: either show completions for all possible
    branches across all repositories (useless), or give up on completion entirely
    for these options.

    Optique 0.10.0 introduces a dependency system that solves this problem while
    preserving 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 if
    csv is true, you'll have a delimiter field. The parser enforces this at
    runtime, and shell completion will suggest --pretty only when --json is
    present.

    This works well when the valid combinations are known at definition time. But
    it can't handle cases where valid values depend on runtime input—like
    branch 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 user
    typed for the dependency option. Optique 0.10.0 introduces dependency() and
    derive() to handle exactly this.

    The dependency system

    The core idea is simple: mark one option as a dependency source, then create
    derived 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 source
    const repoParser = dependency(string());
    
    // Create a derived parser
    const 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 the
    actual value the user provided for --repo and returns a parser that validates
    against refs from that specific repository.

    Under the hood, Optique uses a three-phase parsing strategy:

    1. Parse all options in a first pass, collecting dependency values
    2. Call factory functions with the collected values to create concrete parsers
    3. Re-parse derived options using those dynamically created parsers

    This means both validation and completion work correctly—if the user has
    already typed --repo /some/path, the --ref completion will show refs from
    that path.

    Repository-aware completion with @optique/git

    The @optique/git package provides async value parsers that read from Git
    repositories. Combined with the dependency system, you can build CLIs with
    repository-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>, the
    completion will show branches from /path/to/project. The defaultValue of
    "." means that if --repo isn't specified, it falls back to the current
    directory.

    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. If
    some dependencies aren't provided, Optique uses the defaultValues.

    Async support

    Real-world dependency resolution often involves I/O—reading from Git
    repositories, querying APIs, accessing databases. Optique provides async
    variants 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, so
    gitBranch(), gitTag(), and gitRef() all work in both Node.js and Deno.

    There's also deriveSync() for when you need to be explicit about synchronous
    behavior, and deriveFromAsync() for multiple async dependencies.

    Wrapping up

    The dependency system lets you build CLIs where options are aware of each
    other—not just for validation, but for shell completion too. You get type
    safety throughout: TypeScript knows the relationship between your dependency
    sources and derived parsers, and invalid combinations are caught at compile
    time.

    This is particularly useful for tools that interact with external systems where
    the set of valid values isn't known until runtime. Git repositories, cloud
    providers, databases, container registries—anywhere the completion choices
    depend 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/core@0.10.0-dev.311
    

    Or with npm:

    npm install @optique/core@0.10.0-dev.311
    

    See the documentation for more details.

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

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 0 Votes
    1 Posts
    6 Views
    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.
  • 0 Votes
    4 Posts
    6 Views
    @oblomov When using `checked` or `hidden` I do like not to add any value.```<input type="checkbox" checked />```Here's an interesting take with link to the HTML spec:https://mastodon.social/@shinspiegel/115530101220632082
  • 0 Votes
    1 Posts
    10 Views
    How to emulate hand-drawn shapes / Algorithms behind RoughJS | shihn.caHow to emulate hand-drawn shapes / Algorithms behind RoughJS | shihn.caA dive into graphics algorithms used in RoughJS - A graphics library that lets you draw in a sketchy, hand-drawn-like, style.How to emulate hand-drawn shapes / Algorithms behind RoughJShttps://monodes.com/predaelli/2025/10/24/how-to-emulate-hand-drawn-shapes-algorithms-behind-roughjs-shihn-ca/#Documentations #Javascript
  • 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!