dedup

Dedup

tl dupes finds duplicates; removing them well is the skill. Most of the output is noise, the wins hide in two tiers, and the mitigation that actually sticks is non-obvious: you remove the second home, not "fix both copies."

Workflow

Scan → Triage → Mitigate → Verify → Ratchet

1. Scan

tl dupes --near        # structural + near surfaced first; tests excluded by default

Via the MCP tool, near is a number (the similarity threshold), not a flag: mcp__callmux__tl_dupes { near: 0.85 }. Passing near: true fails schema validation — the CLI's bare --near defaults that threshold for you.

Files copied verbatim into another tool (e.g. a plugin shipped into a user's config dir) are external contracts — their duplicate helpers are by-design, not cleanup targets. tl dupes excludes them by default. Mark your own in .tokenleanrc.json:

{ "externalContractFiles": ["src/my-copied-plugin.js"] }

Use tl dupes --near --include-contracts only when you deliberately want to audit those copies too.

2. Triage by tier — signal vs. noise

tl dupes returns four tiers. Treat them differently:

• Structural + near = signal. Renamed clones and copy-paste-with-edits — the drift-prone ones. Start here.
• Exact = quick wins, but check intent first. Two trivial pass-throughs colliding (return [...this.x.values()]) aren't always worth a shared home.
• Names = mostly noise. Idiomatic repeats (update, close, get, logger levels). Skim, don't mine — add --no-names once you've glanced.

3. The "real dupe?" test

The rule that separates worth-fixing from leave-it:

• Same rule encoded twice → collapse it. Validation, response unwrapping, a path-containment check, a magic constant, a normalization step. These are the drift hazards: one copy gets a fix, the other doesn't, and a phantom bug surfaces weeks later.
• Same shape by coincidence → leave it. Logger debug/info/warn/error, SSE emit* helpers, store thunks, thin HTTP wrappers. Merging hurts readability for zero safety gain.