npm Simple Name Series

Key Challenges & Strategic Objectives

1. The naming had to be the strategy, not a gimmick. why-is-this-slow isn’t a clever product name — it’s a search term. Developers searching npm for a memory diagnostic don’t search for “Node.js memory profiler.” They type what they said. The series is built on one observation: name the tool after the complaint, and it appears at the point of frustration rather than the point of research. Every name in the series is a verbatim developer sentence, chosen because it’s what people already type.
2. Every tool had to know its limits. who-ate-my-ram reports likely, possible, or weak signal — never a definitive answer. what-is-this-package-actually-doing tells you what it can observe, not what it can prove. The diagnostic value of each tool depends entirely on the developer trusting the output. Overconfident output destroys that trust. Each tool is explicitly scoped: it tells you where to look and stops there.
3. Zero friction was non-negotiable. Developers debugging a broken system don’t have patience for onboarding. Every tool runs with npx — no installation, no config file, no API key, no account. The cost to try is one command. That’s a positioning decision: meet the developer at the exact moment of frustration and remove every obstacle between them and an answer.
4. what-is-this-package-actually-doing required a different architecture entirely. Most npm security tools work statically — they scan code without running it. This tool runs the package in a sandboxed temp directory, injecting a CJS tracer preload via --require before any package code executes. It intercepts http, https, fs, and child_process at the module layer and records actual behavior at require-time. A package can obfuscate a fetch() call. It cannot hide a real HTTP request from a network interceptor. It is the only tool in the series with two build outputs.

Technical Solution & Architecture

Five tools, one standard. TypeScript 5, Node 18+, tsup, Vitest, chalk as the sole runtime dependency across all five. Every tool exits with code 1 on errors — designed for CI pipelines, not just developer terminals.

Outcomes & Results

Five tools published. Three more in active development.

• Tools shipped: 5, all under @workingmodel/ npm org.
• Combined tests: 103 across the series.
• Runtime dependencies per tool: 1 (chalk).
• Configuration required: 0.
• License: MIT across all five.
• Search path owned: npm search why.

We built them because we needed them. Published them because the search space was empty.

What This Means

The names aren’t clever. They’re functional. npm search why is a real search path. The series is designed to show up there — not through SEO manipulation, but by being exactly what the query describes.

Five tools with the same voice, the same structure, the same naming convention, the same one-dependency rule, and the same plain-English output philosophy is a statement. Developer experience is a design problem. The right answer to “how should this tool be named?” is the same answer as “what does the developer say right before they need it?” In this series, those are always the same sentence.