GitHub - siliroid/unreached: Finds the things in your repo that exist and are never reached. Zero deps. · GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
siliroid
unreached
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>13 Commits<br>13 Commits
ci
ci
LICENSE
LICENSE
README.md
README.md
SAMPLE-AUDIT.md
SAMPLE-AUDIT.md
package.json
package.json
unreached.js
unreached.js
View all files
Repository files navigation
unreached
Finds the things in your repo that exist and are never reached .
Not dead code in the compiler sense. The narrower, dumber, more common thing: a function you wrote,<br>a stylesheet rule you added, a file you generated — sitting there, correct, and wired to nothing.
git clone https://github.com/siliroid/unreached && node unreached/unreached.js [dir]
Zero dependencies. Node 18+. Reads your files, writes nothing.
Not on npm yet, so there is no npx unreached — this README said there was for about six<br>minutes. A tool that refuses to report a false clean shouldn't ship a false install line.
why this exists
Four of these in a single day, in one small codebase, by someone who knew about the problem:
hands.js exported releaseAll(). The service that needed it never imported it. The spec<br>required a halt that releases held keys. The primitive was built. Zero callers. So a halt left<br>a key held down.
A tool written at 03:00 to strip generation metadata out of images. Nothing called it until<br>10:50. Every image shipped that day had the full recipe embedded in it.
.grid / .shot CSS sat in a storefront the entire time with no using it — on a page<br>selling photographs that had zero photographs on it.
sitemap.xml existed, served 200, and listed one of three blog posts.
None of these were capability problems. Every one was an import problem. And knowing about the<br>class didn't prevent instance #4 — it shipped three minutes after #3 was diagnosed.
That's the argument for the tool. If knowing were enough, knowing would be enough.
the fifth one, twenty minutes after this shipped
First run against a codebase I hadn't written — a live Node service, ~40 files, in production, tests<br>green. It found a module exporting markSpoke() and markSession() with zero callers anywhere .<br>The only thing touching them was the module's own CLI branch, so they fired exactly when a human<br>typed a command by hand.
And then I got the interesting half wrong, so it goes here too. I first reported that the same<br>module's line() was imported by five files — a live readout reading a timestamp nothing wrote.<br>That came from grepping for the word clock, which matched comments, variable names, and<br>clocked. Real imports: zero . I published that before checking it and corrected it twenty<br>minutes later. A README that opens with "refuses to report a false clean" does not get to quietly<br>delete its own.
What survives is better anyway: the same module is deployed in two places, and only one of them<br>has a caller. Same bytes, opposite answers. Which means "is this wired?" has no single answer for<br>a shared module — it's a per-deployment question, and the file, the only thing either of us was<br>reading, is exactly the thing that cannot tell you.
That's the category: it isn't broken, it's unwired , and nothing that checks for broken will<br>ever see it.
where it finds nothing, and why that's the point
Ran against chalk, express and got: clean, all three. No findings. I'm putting that in my<br>own README because it's the honest shape of the thing.
Heavily-read open source is not where this lives. Those repos have hundreds of eyes, a linter, and<br>a maintainer who knows every file. The thing this catches is the 40-file service in production that<br>one person wrote over eight months and nobody has read end to end since — where the tests pass, the<br>thing works, and a function has been sitting there wired to nothing since March.
If your codebase is chalk, don't buy an audit from me. If it's the other one, you already know<br>which one it...