larprober logo, an ink bottle with three strokes rising from it larprober
02

A linter for machine written code

tellsign

A zero dependency command line tool that reads a codebase and reports the specific ways generated JavaScript goes wrong, by family rather than by line.

Year
2026
Type
Command line tool
Stack
Node 24, zero dependencies
Status
Published on npm and GitHub

github.com/larprober/tellsign npm: tellsign

The brief

Machine written JavaScript fails in repeatable shapes: an import of a package that was never installed, a call to an API that does not exist, a dropped await, a guard that can never be false, a comment describing code that has since changed. A normal linter sees none of it, because none of it is a syntax problem. The tool had to name the shape, so a reviewer knows what to look for instead of squinting at a line number.

What it does

Fourteen families, each with its own detector and its own explanation: phantom imports, phantom APIs, crossbreeds, lost awaits, dead guards, scaffold residue, stale docs, muted catches, orphans, twins, barnacles, stale recipes, echo comments and voice.

It installs with nothing: npx tellsign runs it straight from the registry, because there is no dependency tree to resolve.

The design decision worth keeping

There is no parser. A single pass lexer produces a masked copy of every file where strings, template chunks, comments and regular expression literals are blanked out and every byte offset is preserved. Rules match against the mask, so a rule can never trip over a string that merely looks like code, and every finding still maps back to an exact position in the original file. That is what keeps precision high with a dependency count of zero.

How the masked lexer works A source file is drawn as seven segments. Strings, comments and regular expression literals are blanked out in a second copy while the code segments and every byte offset stay in place, so rules match only real code. One pass, two copies no parser source.js code string code comment code regex code masked copy, every byte offset preserved code code code code byte 0 end of file
Rules only ever see the masked copy. A finding can never be triggered by text inside a string or a comment, and because no byte moves, every finding still points at an exact position in the original file.

Proof

  • 33 tests, and a clean scan of its own source.
  • A sweep across 20 local projects. The dominant real finding was 32 empty catch blocks, two projects accounting for most of them.
  • That sweep also produced two classes of false positive: dependencies wired through configuration rather than imports, and wrapped comments being read one line at a time. Both were fixed before the release that followed.

One to remember: an early build used a NUL byte as a glob sentinel, and git committed the source file as binary. The sentinel became a compiled expression instead.

All case studies Next: Reseed

Need something like this?

Describe it in a paragraph. I will tell you whether it is a two day job or a two month one before you commit to anything.

Start a project

Reply within 24 hours on weekdays. Taking new projects.

Taking new projectsReply in 24 hours on weekdays Start a project