npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

whyfail

v0.1.0

Published

Diagnose why your build/test/deploy just failed -- pipe a log in, get cause/explanation/fix.

Downloads

151

Readme

whyfail

Diagnose why your build, test, or deploy just failed -- pipe a log in, get the cause, explanation, fix, and exact commands back. No account, no config, no local backend to run: it talks to the live WhyDidThisFail? API by default.

A thin CLI client for the WhyDidThisFail? API (see the repo root for the Phase 1 service). It has no diagnosis logic of its own -- it collects the failing log text, POSTs it to /diagnose, and prints the result.

Install

No install needed for one-off use:

some-failing-command 2>&1 | npx whyfail

Or install it properly if you'll reach for it often:

npm install -g whyfail     # global, gives you the `whyfail` command everywhere
# or
npm install -D whyfail     # as a project dev dependency, run via `npx whyfail` or an npm script

Requires Node >= 18 (uses the built-in fetch; nothing else to install -- this package has zero runtime dependencies).

Usage

# Piped input -- the core workflow: pipe a failing command straight in
some-failing-command 2>&1 | npx whyfail

# From a saved log file (e.g. downloaded from a CI run)
npx whyfail ./build.log

# Interactive paste (for a failure you only have in a CI dashboard, Slack, etc.)
npx whyfail --paste

A real worked example

$ python -c "import definitely_not_installed" 2>&1 | npx whyfail

 ✓ KNOWN ISSUE — pattern-matched
matched pattern: py-module-not-found

Format: python
Error: ModuleNotFoundError: No module named 'definitely_not_installed'
Location: <string>:1

Cause
The package providing 'definitely_not_installed' is not installed in the current Python environment.

Explanation
Python looked for a module named 'definitely_not_installed' on sys.path and couldn't find it. This
almost always means the package isn't installed, is installed in a different virtual
environment/interpreter than the one running the code, or the module name differs from the pip
package name.

Fix
Install the package that provides 'definitely_not_installed' into the environment you're running
with, and double-check you're using the interpreter/virtualenv you think you are.

Commands
  $ pip install definitely_not_installed
  $ python -c "import sys; print(sys.executable)"

Options

| Flag | Description | | --- | --- | | --json | print the raw API response as JSON, for scripting | | --format <type> | hint the log format (python | npm | docker | github_actions | typescript | terraform) instead of auto-detecting | | --api-url <url> | override the API base URL | | -h, --help | show usage |

API URL resolution

--api-url flag > WHYFAIL_API_URL env var > the live production API (https://whydidthisfail-production.up.railway.app).

A fresh install needs zero configuration -- it hits the production backend automatically. Override with --api-url or WHYFAIL_API_URL only if you're running your own instance of the Phase 1 API (e.g. local development against the repo root, or a self-hosted deployment):

npx whyfail --api-url http://localhost:8000 ./build.log
# or
export WHYFAIL_API_URL=http://localhost:8000

Output

Results are visually tagged by where they came from:

  • ✓ KNOWN ISSUE — pattern-matched -- matched a known, common error in the API's pattern database. Fast, and the fix has been seen before.
  • ✨ AI ANALYSIS — novel issue -- no known pattern matched; this is Claude's best-effort analysis of something new.

Every result shows the detected format, the extracted error signal (so you can confirm the tool found the right error), cause, explanation, fix, and copy-pasteable exact commands.

Exit codes

0 on any successful diagnosis (pattern-matched or LLM). Non-zero only on a genuine tool error: the API was unreachable, the input couldn't be read, or no input was provided at all. There's no pass/fail verdict here, so exit code doesn't encode one.

Development

npm link   # from this directory, to test `whyfail` locally as if installed

Zero runtime dependencies -- relies on Node's built-in fetch (Node >= 18).

To point a locally-linked CLI at a locally-running Phase 1 API instead of production while developing, use --api-url http://localhost:8000 or set WHYFAIL_API_URL (see "API URL resolution" above).