Add an output filter for deno
h5i compresses noisy command output before it reaches an agent's context (this powers h5i capture run). Filters are small declarative TOML rule files under assets/filters/, embedded into the binary at build time. This is a self-contained good-first-issue: add a filter for deno. No changes to core logic are needed.
Why
deno test/lint/check print per-item progress; the signal is failures, diagnostics, and the test/lint summary.
What to keep / strip
- Keep (the signal): failing test/lint names, error diagnostics, and the
N passed; M failed summary.
- Strip (the noise):
ok/passing lines, download notices, and blank lines.
Steps
- Create
assets/filters/deno.toml.
- Match the command with a
match_command regex, e.g. match_command = "^deno\\b". Make it match typical invocations but not unrelated commands.
- Use the fields below to strip the noise and keep the signal.
- Add 2–3 inline golden tests (
[[tests.deno]]): a normal run, an error/failure run, and a clean/empty run if relevant.
Available fields (see src/filter_rules.rs)
description, match_command, strip_ansi, replace (pattern/replacement), match_output (pattern/message/unless), strip_lines_matching, keep_lines_matching, truncate_lines_at, head_lines, tail_lines, max_lines, on_empty.
Copy an existing filter as a starting point — e.g. eslint.toml (line-strip style) or ping.toml (tail-only style).
Golden-test shape
[filters.deno]
description = "…"
match_command = "^deno\\b"
strip_ansi = true
strip_lines_matching = [ "^\\s*$" ]
[[tests.deno]]
name = "keeps the summary, drops the noise"
input = """…raw output…"""
expected = """…filtered output…"""
How to verify
cargo test builtin_golden_tests_pass # runs every filter's inline golden tests
cargo test --test filter_quality # token-cut + signal-preservation checks
(On low-RAM machines, build single-job: cargo build -j1.)
Reference
The upstream rtk project supports the Deno toolchain — see its src/filters/ and src/cmds/ for inspiration on what matters in the output. h5i's filters are derived from rtk (see assets/filters/NOTICE).
Acceptance criteria
Add an output filter for
denoh5i compresses noisy command output before it reaches an agent's context (this powers
h5i capture run). Filters are small declarative TOML rule files underassets/filters/, embedded into the binary at build time. This is a self-contained good-first-issue: add a filter fordeno. No changes to core logic are needed.Why
deno test/lint/checkprint per-item progress; the signal is failures, diagnostics, and the test/lint summary.What to keep / strip
N passed; M failedsummary.ok/passing lines, download notices, and blank lines.Steps
assets/filters/deno.toml.match_commandregex, e.g.match_command = "^deno\\b". Make it match typical invocations but not unrelated commands.[[tests.deno]]): a normal run, an error/failure run, and a clean/empty run if relevant.Available fields (see
src/filter_rules.rs)description,match_command,strip_ansi,replace(pattern/replacement),match_output(pattern/message/unless),strip_lines_matching,keep_lines_matching,truncate_lines_at,head_lines,tail_lines,max_lines,on_empty.Copy an existing filter as a starting point — e.g.
eslint.toml(line-strip style) orping.toml(tail-only style).Golden-test shape
How to verify
(On low-RAM machines, build single-job:
cargo build -j1.)Reference
The upstream
rtkproject supports the Deno toolchain — see itssrc/filters/andsrc/cmds/for inspiration on what matters in the output. h5i's filters are derived from rtk (seeassets/filters/NOTICE).Acceptance criteria
assets/filters/deno.tomladded with a cleardescriptionmatch_commandmatches typicaldenoinvocations and not unrelated ones