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 on

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 0 Votes
    1 Posts
    5 Views
    Learning zero-width joiners like#javascript #unicode
  • 0 Votes
    1 Posts
    7 Views
    Fedify 1.10.0: Observability foundations for the future debug dashboard Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities. We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications. This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface. Enhanced OpenTelemetry instrumentation Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values. The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations: activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation Additionally, Fedify now instruments previously uncovered operations: activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo. Distributed trace storage with FedifySpanExporter Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers. The new @fedify/fedify/otel module provides the following types and interfaces: import { MemoryKvStore } from "@fedify/fedify"; import { FedifySpanExporter } from "@fedify/fedify/otel"; import { BasicTracerProvider, SimpleSpanProcessor, } from "@opentelemetry/sdk-trace-base"; const kv = new MemoryKvStore(); const exporter = new FedifySpanExporter(kv, { ttl: Temporal.Duration.from({ hours: 1 }), }); const provider = new BasicTracerProvider(); provider.addSpanProcessor(new SimpleSpanProcessor(exporter)); The stored traces can be queried for display in debugging interfaces: // Get all activities for a specific trace const activities = await exporter.getActivitiesByTraceId(traceId); // Get recent traces with summary information const recentTraces = await exporter.getRecentTraces({ limit: 100 }); The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace. This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234. Optional list() method for KvStore interface Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries. interface KvStore { // ... existing methods list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>; } When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method: MemoryKvStore — filters in-memory keys by prefix SqliteKvStore — uses LIKE query with JSON key pattern PostgresKvStore — uses array slice comparison RedisKvStore — uses SCAN with pattern matching and key deserialization DenoKvStore — delegates to Deno KV's built-in list() API WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle. The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers. NestJS 11 and Express 5 support Thanks to a contribution from Cho Hasang (@crohasang@hackers.pub), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4. This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications. What's next Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available. The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release. Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies. Acknowledgments Special thanks to Cho Hasang (@crohasang@hackers.pub) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features. For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository. #fedidev #release
  • 0 Votes
    3 Posts
    8 Views
    BotKitは、ActivityPubボットを作るためのTypeScriptフレームワークです。既存のMastodon/Misskeyボットとの違いは、ボット自体が独立したサーバーとして動作すること。プラットフォームのアカウントは不要です。 文字数制限もなければ、APIレート制限に悩まされることもありません。 bot.onMention = async (session, message) => { await message.reply(text`こんにちは、${message.actor}さん!`); }; フェデレーション、HTTP Signatures、配送キューといったActivityPub周りの処理はFedifyがすべて引き受けます。ボットのロジックを書くだけです。 DenoでもNode.jsでも動きます。 https://botkit.fedify.dev/ #BotKit #Fedify #ActivityPub #TypeScript #Deno #NodeJS
  • 0 Votes
    1 Posts
    12 Views
    Anyone aware of #Javascript jobs at a not evil/impactful company? I’ve got 15 years of experience, fluent in React and NodeJS with Express. Experience with Postgres, SQLite and NoSQL databases. Got my last company Cyber Essentials Certified. Im proficient in dev ops and sys admin. Have a small (but growing!) portfolio of FOSS work.Have an extensive background in teaching programming too, so can mentor juniors. I LOVE mentoring. Have an academic background too. #GetFediHired boosts welcome 💖