feat(pnpm): Add filter argument support

[KuSh]

• Add support for pnpm global filter arguments (--filter) across all pnpm commands (list, outdated, install, etc.).
• Merge pnpm filters with native command arguments (--filter + custom args like --depth).
• Implement proper handling for Vec<String> (text filters) and Vec<OsString> (OS-specific filters).
• Add unit tests for merge_pnpm_args and CLI parsing to validate expected behavior.

This enables users to apply workspace-specific filtering directly via --filter @scope before running pnpm commands, reducing token overhead by excluding irrelevant packages/dependencies from output.

Fixes: #259

[FlorianBruniaux]

Hi @KuSh! Quick ask — PR #241 just merged to master. Could you rebase this PR? One file change, should be straightforward. We'll review once it's current.

[KuSh]

Hi @FlorianBruniaux, done!

[aeppling]

Review: feat(pnpm) Add filter argument support

Good addition overall — the approach is clean, additive, follows the existing Git global-args pattern, and all 623 tests pass with no new clippy warnings. A few things to address before merging:

---

Required

Build and Typecheck silently ignore --filter

When a user runs rtk pnpm --filter @app1 build, the filter is destructured but never used — no warning, no error. This will confuse users who expect filtering to apply.

At minimum, emit a warning when filters are provided with these subcommands:

if !filter.is_empty() {
    eprintln!("[rtk] warning: --filter is not yet supported for pnpm build, filters will be ignored");
}

Same for Typecheck. The FIXME comments acknowledge the gap but the silent discard is a UX issue that should not ship as-is.

---

Recommended (not blocking, but would strengthen the PR)

Missing test coverage for edge cases:

• Empty filters: verify merge_pnpm_args(&[], &args) returns args unchanged (backward-compat)
• Multiple --filter flags in CLI parsing: ["rtk", "pnpm", "--filter", "@app1", "--filter", "@app2", "list"] — only single filter is tested today
• Other passthrough with filters: the OsString path is only tested at the helper level, not through CLI parsing → dispatch
• Build/Typecheck with filters: document the expected behavior (filters ignored + warning)

---

Nits

• The doc comment on merge_pnpm_args_os is a copy-paste of merge_pnpm_args — should mention it's the OsString variant
• args.iter().map(|arg| arg.to_string()) in merge_pnpm_args could be .chain(args.iter().cloned()) — more idiomatic since String: Clone

[aeppling]

After reviewing the PR we could merge this, user has informed with // FIXME and this is not blocking nor an real issue but a limitation.
Limitation is flagged and PR is valid.

[KuSh]

I'll take review feedback into account, not too complicated and it helps develop skills

[KuSh]

@aeppling your feedback is normally taken into account.

[pszymkowiak]

Rebased on develop, fixed two issues along the way:

1. Added -F short form (#[arg(long, short = 'F')]) — pnpm accepts -F as alias for --filter
2. Fixed validate_pnpm_filters return value that was silently discarded — now prints the warning via eprintln!
3. pnpm build now routes through passthrough with filter merge (instead of next_cmd::run)

907 tests pass. @adrimusic could you review this one?

[KuSh]

Thanks for lending a helping hand @pszymkowiak. I've made some fixes and additions:

• Now that PnpmCommand::Build is simply another passthrough I've removed it completely
• I've also removed the eprintln! call in validate_pnpm_filters to avoid double printed warning
• There were some files added inadvertently, I've removed them
• A git test was failing on my linux computer. I've fixed it (cmd.get_program() is returning /usr/bin/git instead of just git)

[CLAassistant]

All committers have signed the CLA.