rtk-ai/rtk

Allow user TOML filters to customize built-in command output

Open

#821 创建于 2026年3月25日

在 GitHub 查看
 (1 评论) (0 反应) (0 负责人)Rust (2,914 fork)batch import
area:configeffort-mediumenhancementfilter-qualityhelp wantedpriority:medium

仓库指标

Star
 (48,085 star)
PR 合并指标
 (平均合并 11天 1小时) (30 天内合并 45 个 PR)

描述

Problem

Built-in Rust commands (git, kubectl, npm, docker, etc.) are routed by Clap before the TOML engine runs. User TOML filters can only target commands that RTK doesn't already handle natively.

This means there's no way to customize how built-in commands filter output. For example, kubectl top and kubectl exec go through the built-in kubectl handler, but their output characteristics are very different from kubectl get. A user can't write a TOML filter to handle kubectl top differently because kubectl as a whole is claimed by the Rust binary.

Use case

# This doesn't work — kubectl is a built-in command
[filters.kubectl-top]
description = "Compact kubectl top output"
match_command = "^kubectl\\s+top\\b"
strip_ansi = true
strip_lines_matching = ["^\\s*$"]

The TOML engine never sees kubectl top because Clap routes all kubectl * to the built-in handler first.

Proposed approach

Allow user TOML filters to match specific subcommands of built-in commands. For example, if a user defines a filter matching ^kubectl\s+top\b, it should take precedence over the generic built-in kubectl handler for that specific subcommand pattern.

The priority could be: user TOML (specific subcommand match) > built-in Rust handler > user TOML (generic).

Happy to send a PR if this approach makes sense.

贡献者指南