洪 民憙 (Hong Minhee) :nonbinary:'s avatar

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 1004 following · 1438 followers

An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in , , , & . They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

I've been using this exact distinction for a while now. Since Korean, my native language, has distinct terms for the system (런타임), the point in time (實行時(실행 시)), and the duration (實行時間(실행 시간)), using a single spelling for all three in English always felt a bit blurry to me. This spelling convention helps bridge that gap and makes technical writing much more precise.

Personally, I find the meaning as indicated by Google's style guide the most clear, combined with an explicit case for hyphenation:

Runtime: use the system meaning. E.g. “the runtime was updated last week,” or “I'm using version 21 of the Java runtime.”

Run-time: use the moment meaning, but only when used in the adjective position. E.g. “run-time instrumentation is useful for finding bugs.”

Run time: use the duration meaning. E.g. “the run time was reduced by 5%,” or “a run time of five minutes is unacceptable.” In addition, when you want to use the moment meaning, but not as an adjective, this form should also be used. E.g. “typechecking happens at run time in our implementation.”

My Opinion on Run Time vs. Run-time vs. Runtime (by Bob Rubbens)

Lobsters

@lobsters@mastodon.social

My Opinion on Spelling Run Time vs. Run-time vs. Runtime lobste.rs/s/vnkwyb
bobrubbens.nl/post/my-opinion-

Christine Lemmer-Webber's avatar
Christine Lemmer-Webber

@cwebber@social.coop · Reply to Evan Prodromou's post

@evan *screaming in sharedInbox's design concession at the end of AP's standardization was already my biggest regret and this makes it much worse*

Evan Prodromou's avatar
Evan Prodromou

@evan@cosocial.ca · Reply to Evan Prodromou's post

You don't have to answer this if you don't know what it means.

The relevant section of the ActivityPub specification is here:

w3.org/TR/activitypub/#shared-

Evan Prodromou's avatar
Evan Prodromou

@evan@cosocial.ca

Should ActivityPub servers send public activities to all known `sharedInbox` endpoints on the network?

OptionVoters
Yes16 (16%)
Yes, but...22 (21%)
No, but...28 (27%)
No37 (36%)
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to Dave bauer's post

@davebauerart Exactly. It's amazing how much code can teach us about people. Keep building those bridges!

Elena Rossini ⁂'s avatar
Elena Rossini ⁂

@_elena@mastodon.social

Oooooh my custom made sweatshirt has arrived at a pickup point! Going to retrieve it later today and I hope it turned out ok.

I intend to wear it at on the big day for the Social Web talks.

All fingers and toes crossed it looks good and fits well. Otherwise I have two other Fedi t-shirts as backups 😅

a photo showing the mockup for a sweatshirt - color: forest green - with the words "the future is federated" printed in white. The font is Eighties Comeback by independent type designer Nicky Laatz
ALT text detailsa photo showing the mockup for a sweatshirt - color: forest green - with the words "the future is federated" printed in white. The font is Eighties Comeback by independent type designer Nicky Laatz
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to b00g13's post

@b00g13 Thank you! I strongly agree that code quality and maintainability will always be valuable, no matter how the industry evolves. I really appreciate your encouragement to stick to high standards.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to veroandi's post

@veroandi Thank you for recognizing that. It's comforting to know that our quiet contributions are seen and valued as a force for good. It makes me feel less alone in this.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to ged's post

@ged You're right. Finding that why really changes everything. It turns work into joy, and that energy keeps me going. Thank you for such a warm perspective!

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to Anders Cornelius Madsen's post

@madsenandersc Thank you for sharing such a personal story. It truly warms my heart to hear that your son has found his tribe. I know how life-changing that feeling of belonging can be. I wish him all the best!

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to Ramnarayan Kalyanaraman's post

@ramkay I am deeply moved by your words. Knowing that my work has earned the respect of users like you gives me the strength to keep contributing. Thank you.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to John O'Nolan's post

@john Thank you, John! Ghost's support has been a huge motivation for me to keep going. I'm proud that we're building the open web together.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to Albert Mantingh's post

@albertmantingh Thank you. That means a lot to me.

티르's avatar
티르

@tirr@mitir.social

JPEG XL 이미지 포맷 지원이 Chromium에 머지되어서 지금 Canary 빌드에서 플래그를 켜면 사용해볼 수 있다.

구현체로 jxl-rs를 사용하는데 저도 상당부분 기여했습니다 많관부...
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

I've spent a long time asking myself why open source matters so much to me, why I keep coming back to it. I once joined a company purely because they promised I could do open source full-time (it didn't turn out well). Before that, I was doing open source inside and outside of regular jobs. And now, in the age of LLMs, when the value of code itself seems to be declining, I'm still here, still doing this.

Recently it clicked. I do open source because it's social work—in the sense that it lets me participate in society.

Everyone wants to belong to some community, to connect with others. But I was never good at the usual ways of doing that. Social activities that came naturally to others were difficult for me. In school, I had few friends. After class, I'd stay home assembling Lego or reading books alone. Then I discovered coding.

Coding was a wonderful hobby for me, especially because I encountered it at the dawn of the internet era. The first programming languages I properly learned were Perl, PHP, and JavaScript—all languages of the internet age. The synergy was something else.

Gradually I fell into the world of open source. And there, even someone like me—awkward at conventional social interaction—could be social. My code helped people. I could collaborate by exchanging code. I could have conversations, mediated by code. IRC, mailing lists, forums—these became my social media. Over time, “the group I wanted recognition from” became the people in the open source world. I didn't care much about being recognized by classmates, but I wanted to be recognized by these people I'd never met face to face.

That mindset still shapes me now, approaching forty. I still care more about recognition from open source programmers than from colleagues. The social activity that happens in open source communities is, after my family, the most important social activity in my life.

The specific things I build, the technical details—those matter less than I used to think. I just want to do the kind of social activity that suits me, and open source happens to be the way I do it.

That's all, really.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Hongdown 0.2.0 is out! Hongdown is an opinionated formatter written in , and this release brings support, so you can now use it as a library in .js, , , and browsers.

New features:

  • Smart heading sentence case conversion with ~450 built-in proper nouns
  • SmartyPants-style typographic punctuation ("straight"“curly”)
  • External code formatter integration for code blocks
  • Directory argument support for batch formatting

Try it in the browser: https://dahlia.github.io/hongdown/

Release notes: https://github.com/dahlia/hongdown/discussions/10

Anthony Fu's avatar
Anthony Fu

@antfu.me@bsky.brid.gy

if people no longer read the code, API is no longer targeting humans, is there still a need for "good API design"? is it still worth the effort to figure out what would be the best for users, instead of the best of ai to understand/use? I don't know.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

CLIツールを作ってると、「--repoで指定したリポジトリのブランチだけ補完候補に出したい」みたいな場面があるんですよね。でも普通のCLIパーサーだと各オプションが独立してて、これが意外と難しい。

TypeScript向け型安全CLIパーサーOptiqueで、この問題を解決する仕組みを作ったので、記事にまとめました。

https://zenn.dev/hongminhee/articles/aedde5d7fcc40e

Lobsters

@lobsters@mastodon.social

Your CLI's completion should know what options you've already typed by @hongminhee lobste.rs/s/5se1tq
hackers.pub/@hongminhee/2026/o

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

When building CLI tools, shell completion usually treats each option in isolation. But sometimes valid values for one option depend on another—like branch names depending on which repository you're targeting.

Wrote about how I solved this in Optique, a type-safe CLI parser for TypeScript.

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

洪 民憙 (Hong Minhee)'s avatar
洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub

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

檀馨 (단형/ダンキヨウ)'s avatar
檀馨 (단형/ダンキヨウ)

@nesroch@mastodon.online

① CJK 환경에서 리눅스의 사용편의성이 윈도에 비견될만한가?
 아니요, 아직 멀었음. 이건 전제로 두고 이야기를 시작함.
② 리눅스 시스템 관리에 CLI가 필수이거나 UAC가 켜져있는 윈도보다 더 크게 불편한 점이 있는가?
 전혀 아니요, 10년도 더 전에 리눅스 써보고 그 경험이 아직도 유효하다고 생각하시면 안 됨. 요즘 전부 GUI로 클릭 두세 번에 다 해결되고, 윈도랑 크게 차이도 안 남.
③ 리눅스 한국어 입력기에 근본적인 사용성 문제가 있는가?
 아니요, OOTB로 작동하지 않는 것 이외에, IBus나 Fcitx에 근본적인 사용성 문제가 있다는 생각은 한 번도 해본 적 없음.

洪 民憙 (Hong Minhee)'s avatar
洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub

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

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

I've been working on a tricky problem in Optique (my CLI parser library): how do you make one option's value affect another option's validation and shell completion?

Think git -C <path> branch --delete <TAB>—the branch completions should come from the repo at <path>, not the current directory.

I think I've found a solution that fits naturally with Optique's architecture: declare dependencies between value parsers, then topologically sort them at parse time.

const cwdString = dependency(string());

const parser = object({
  cwd: optional(option("-C", cwdString)),
  branches: multiple(argument(
    cwdString.derive({
      metavar: "BRANCH",
      factory: dir => gitBranch({ dir }),
      defaultValue: () => process.cwd(),
    })
  )),
});

Details in the issue:

https://github.com/dahlia/optique/issues/74#issuecomment-3738381049

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to marius's post

@mariusor No worries at all! It's always helpful to hear different perspectives. Thanks for the feedback!

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

김칩스 먹고 싶은데, 近處(근처)에서 살 수 있는 곳이 없다… 온라인으로 注文(주문)해야 하나…? 😩

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to marius's post

@mariusor I think there might be a misunderstanding here. The defaultValue function isn't the parser introspecting application logic—it's the opposite direction. The application injects the fallback behavior into the parser.

The parser doesn't need to know what that function does internally. It just calls it when the dependency option is absent. This is similar to dependency injection: the parser defines when to call the function, but the application defines what it does.

Without this, the alternative would be post-parse validation in application code, which loses the benefit of parse-time validation and, more importantly, shell completion—which was the original motivation for this feature.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to marius's post

@mariusor That's a good point for the Git example! However, from Optique's perspective as a general-purpose CLI parser, I don't think we can always assume that.

Some cases where a default value isn't straightforward:

  • The dependency option might be required with no default (e.g., --database <name> for table completions)
  • The default might need async computation (e.g., auto-detecting a Git root by traversing up directories)
  • Computing the default might be expensive, so we'd want to defer it until we know the option wasn't provided

That's why the current design has an explicit defaultValue function as the second argument to derive()—it gives users control over what happens when the dependency option is absent.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

I've been working on a tricky problem in Optique (my CLI parser library): how do you make one option's value affect another option's validation and shell completion?

Think git -C <path> branch --delete <TAB>—the branch completions should come from the repo at <path>, not the current directory.

I think I've found a solution that fits naturally with Optique's architecture: declare dependencies between value parsers, then topologically sort them at parse time.

const cwdString = dependency(string());

const parser = object({
  cwd: optional(option("-C", cwdString)),
  branches: multiple(argument(
    cwdString.derive({
      metavar: "BRANCH",
      factory: dir => gitBranch({ dir }),
      defaultValue: () => process.cwd(),
    })
  )),
});

Details in the issue:

https://github.com/dahlia/optique/issues/74#issuecomment-3738381049

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

It seems like the Claude models normalize all curly quotes into straight quotes, which is incredibly annoying for someone like me who uses curly quotes all the time.

Older →