DEV Community: Ofri Peretz

Three of My Planned Articles Cited Numbers That Do Not Exist

Ofri Peretz — Thu, 12 Nov 2026 02:20:22 +0000

I keep a document listing twelve articles I intend to write, each with a
measured number behind it. Before writing any of them I checked the numbers
against the benchmark JSON the document names as its source.

Two of them appear in no result file anywhere. A third contradicts the
file it cites. A fourth is a real number attached to the wrong subject.

Nothing had flagged this, because nothing recomputes prose.

What the audit found

The document says one plugin produced 981 findings against another's
21,557. The JSON it cites says 1,375 and 23,325.

grep -rlF 21557 across every result file returns nothing. So does 4311, the
other figure in that row. Not "in a different run" — in no run.

Then the subtler one. The document says a dominant rule accounts for 87% of a
plugin's output and that "every other rule combined accounts for 0.6%." The
87% is exactly right: 20,334 of 23,325. The 0.6% is a real number too — it is
the sum of the bottom five rules, 142 findings. Every other rule is 2,991,
which is 12.8%.

Nothing was invented. A correct figure drifted one clause away from the set it
describes, and in that position it is twenty times wrong.

Four ways a number goes bad in prose

mode	example
no source at all	`21,557` — in no result file
contradicts its own cited source	`981` where the JSON says `1,375`
real number, wrong subject	`0.6%` = bottom five rules, not "every other rule"
contradicted by a later run	"297 files" where the result data records 1

Only the third is catchable by careful reading. The rest require the source
open next to the prose, which is exactly the thing nobody does when the
document reads fluently.

Why the document could not fail

The JSON is generated. Re-run the benchmark and every number in it is replaced.
If a figure is wrong, the next run makes it right, and if the harness breaks the
run fails.

The document is written. It has no relationship to the data except that a person
once read one and typed into the other. It cannot be re-run. It has no failing
state. A number in it is not a measurement — it is a memory of a
measurement,
and memories are not version-controlled against the thing they remember.

This is the same shape as a metric standing in for the thing it
measures: the document was
treated as the source because it was the artifact people actually read.

What it cost

Three of the twelve are dropped for the drift above. Not rewritten — dropped,
because their central claims rest on figures nobody can re-derive, and an
article whose number cannot be reproduced is worth less than no article.

Six more went for other reasons once I started checking: defects already fixed
since the document was written, a claim I could not test with the data on hand,
one topic already covered better elsewhere. Three of twelve survived, and
those three are written.

I would have written most of the other nine without checking.

The habit

Two rules, both cheap.

Never let a number live only in prose. If it matters, it belongs in a
generated artifact the prose points at. A README that states a benchmark result
should render it from the result file, or link to it, or both.

Before you cite your own document, grep the number. Not the claim — the
digits. grep -rlF 21557 results/ takes a second and is the entire audit. It
found two figures that had been sitting in a planning document for weeks,
waiting to be published as fact.

The reason this is worth your attention is that the drift is invisible from the
inside. The document read perfectly well. It was internally consistent, it cited
its source by filename, and every number in it looked like the kind of number
that comes out of a benchmark. It just did not.

Part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

Take the last number you published about your own work. Can you point at the file it came from?

The Most Precise Plugin in My Benchmark Scored 10.8%

Ofri Peretz — Sat, 07 Nov 2026 07:59:36 +0000

Six ESLint security plugins, one labelled corpus of 69 vulnerable fixtures,
same harness, same day — eslint-plugin-security@4.0.1,
@microsoft/eslint-plugin-sdl@1.1.0, ESLint 10.8.1, Node 24.

I wrote the fixtures. That sentence has to come before the table, because
it changes what every row below is worth.

TP, FP and FN are
the four boxes everything below is derived from.

Plugin	TP	FP	FN	F1
Interlace	69	0	0	100%
eslint-plugin-sonarjs	27	9	42	51.4%
eslint-plugin-security	10	7	59	23.3%
@microsoft/eslint-plugin-sdl	6	2	63	15.6%
eslint-plugin-no-unsanitized	4	1	65	10.8%
eslint-plugin-security-node	4	3	65	10.5%

Three rows have a piece of their own, linked above — one tool read closely
rather than ranked. This is seventeen plugins
compressed into one table, and compression is the subject.

Read the column the ranking hides

F1 blends precision and recall, which is how a table like this stops being
informative. Split them and a different tool leads.

eslint-plugin-no-unsanitized sits second from the bottom at 10.8% F1. Its
precision is 80% — 4 true positives against 1 false positive, the highest
of any community plugin here. It detects four things. It is right about
substantially all of them.

That is not a consolation prize. A tool with 80% precision and a narrow scope
is one you leave switched on. A tool that finds more and is wrong more often is
one somebody disables in month three — and a rule nobody runs has a recall of
zero regardless of what the table says.

Why my row says 100%, and why you should discount it

A 100% row against fixtures written by the people who wrote the rules is the
expected outcome of grading your own homework. It is not evidence of
superiority and I will not present it as any.

What it is: a regression gate we happen to publish. It says our rules still
detect what we built them to detect. On the day it stops saying 100%, something
broke.

Three limits follow:

The fixtures encode our threat model. A plugin scoped to a different surface — browser DOM, Angular, Electron — scores low here for reasons that say nothing about its quality on that surface.
F1 on a self-authored corpus measures agreement with our idea of the problem, not correctness in the world.
Recall against 69 of my fixtures is not recall against the field.

@microsoft/eslint-plugin-sdl is the clean example: 15.6% here, and it is a
well-made tool aimed at frontend and Microsoft-stack hardening. Pointing a
Node-backend corpus at it measures the mismatch, not the plugin.

The check I ran before publishing any of it

I did not take the F1 column on trust — including my own row.

Every value was recomputed from its own TP/FP/FN with 2·P·R/(P+R). All six
matched the published figure to within a tenth of a point. Then the check that
actually matters: TP + FN = 69 on every row. If those totals disagreed, the
rows would be describing six differently-scoped runs and the table would not be
a comparison at all.

A minute's work, and the difference between a table you can defend and one you
copied. A number without its measurement is a
memory,
and a rank throws away the distribution behind
it — a leaderboard is
the least recoverable form a measurement can take.

What the table is for

Not for picking a plugin. For two narrower things.

A scope map. The recall column tells you what each tool was built to see.
Four of 69 is not failure; it is a statement of scope, useful when you are
deciding what to run alongside what.

A regression gate. Which is what it is to me, and the only claim here I
would defend without qualification.

If you want the version of this you can trust without knowing me, run it
yourself. The corpus and the harness are in
the plugins repo under
benchmarks/, and the suite that produced this table is one command:

npx tsx benchmarks/suites/ilb-juliet/run.ts

Pin the versions above or your numbers will not match mine — eslint-plugin-security's
recall moves between releases, which is exactly why an unpinned comparison
table is worth nothing. Then add fixtures for the threats you care about. The
result will disagree with mine, and yours will be the one worth having.

Whose fixtures is your security tooling being graded on — and have you ever read them?

My Harness Reported 0 Findings on 100 Files. All 100 Were Ignored.

Ofri Peretz — Tue, 03 Nov 2026 02:15:06 +0000

I ran fourteen lint rules over 100 files and got back zero findings. Every
rule silent, clean sweep, nothing to fix.

The correct answer was 308 findings in 54 of those files. The harness had read
none of them, exited 0, and printed nothing to stderr.

Here are the three ways that happens, all of them measured this week, all of
them silent.

1. The files were outside the base path

ESLint resolves what it is allowed to lint relative to cwd. Point it at a
directory that is not under the cwd of the process, and every file comes back
ignored:

File ignored because outside of base path.

That string arrives as a message with a null ruleId — the same shape as a
parse error. If your loop counts messages.filter(m => m.ruleId), or skips
files whose messages look unfamiliar, you have just discarded the only
explanation you were given.

On the CLI it is quieter still. Exit code 0. Empty stderr.

Fix: set cwd to the tree you are measuring.

2. The `.ts` files were never eligible

Flat config (ESLint 9.39.2 here) matches files by pattern. Omit files, and
the default covers .js and friends — not .ts, in an ecosystem that is
mostly TypeScript.

// eslint.config.mjs
export default [{ rules: { "no-eval": "error" } }];

src/a.ts   ← contains eval()
src/b.js   ← clean

$ eslint .
$ echo $?
0

No output. Exit 0. The .ts file contains eval() and was never opened.

This one is worse than the first, because a partial corpus still produces
plausible numbers. A repository that is 80% TypeScript reports on the other
20% and calls it a result.

Fix: files: ['**/*.ts', '**/*.tsx'], explicitly, and check the count of files
actually linted against a count you obtained some other way.

3. The build under test was not the build you ship

In a monorepo, node_modules/<your-package> is usually a symlink into the
workspace. Anything you measure through it is unreleased source.

I asked a plugin which of its rules carry a fixer. From the workspace:

prefer-event-target: code

From the published package, same command, clean directory:

prefer-event-target: no fixer

Both true. Different questions. I nearly published a correction to a correct
article on the strength of the first one.

Fix: measure in a scratch directory with an npm i <pkg>@<exact-version>, and
say which tree the number came from.

Why all three survive review

Nothing throws. Nothing warns. The exit code is 0 in every case — and the one
time I saw a 1, it came from a real finding in a file that was linted, not
from the file that was skipped. "It exited non-zero, so it noticed" is the
wrong conclusion and I drew it once.

They also fail at three different layers — which files are eligible, which
eligible files are covered, and which build is under test — so fixing one
leaves the others exactly as they were.

And they all fail toward good news. There is no version of these bugs that
invents findings. That asymmetry is what makes them survive: a number that is
too high gets investigated, and a number that is too low gets celebrated.

The check

One rule, before you believe any of it: write the code the tool must flag,
and make sure it flags it.

export function C({ items }: { items: string[] }) {
  return <ul style={{ color: "red" }}>
    {items.map((i) => <li key={i} onClick={() => log(i)}>{i}</li>)}
  </ul>;
}

Four lines, tripping at least two of the rules under test. If the canary is
silent, the corpus number is not a number.

That is what caught mine. The hundred-file zero was completely believable —
it was the four-line file reporting zero that was not.

A count from an instrument you have never seen fail is not a measurement, it is
a hope.

This is the cheap half of what ground truth catches that unit tests
miss:
the tests all passed, because the harness they exercised was working — it was
the corpus it pointed at that was empty. It is also why a result you cannot
re-run is not yet a result, which is the whole distinction between
reproducibility and replicability.
And a zero that means "read nothing" corrupts the one cell every other metric
is derived from — the true-negative box of the confusion
matrix.

Part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

What's the last clean report you got — and would you know if the tool had read nothing?

My Plugin Has 14 Rules. Two of Them Found 60% of Everything.

Ofri Peretz — Thu, 29 Oct 2026 08:43:29 +0000

A plugin's README tells you it has fourteen rules. It does not tell you that on
your codebase, two of them will do almost all of the work and six will never
speak at all.

I measured mine. Fourteen rules in eslint-plugin-react-features that have no
counterpart in eslint-plugin-react, pointed at the 100 .tsx files of this
blog — a public tree, so the numbers below are yours to check rather than mine
to be believed on.

308 findings across 54 files.

The shape

rule	findings	files
`react-no-inline-functions`	113	38
`react-render-optimization`	71	27
`hooks-exhaustive-deps`	42	15
`require-data-slot`	35	14
`no-unnecessary-rerenders`	32	12
`no-inline-style`	9	1
`no-raw-color-literal`	4	2
`no-arbitrary-token-class`	2	2
six rules	0	0

Two rules are 59.7% of the total. Four are 84.7%. The mean is 22 findings per
rule, and the top rule is five times it.

That is not a rule list. That is a power curve with a rule list printed over it.

Why the total is the wrong number

"308 findings" is the number that reaches a standup, and it is the least useful
one available. It is a sum over a distribution nobody looked at, and it invites
exactly the wrong Monday morning — a team triaging 308 things.

Read the table instead and the work is two decisions, not 308. Decide once
about inline functions in JSX. Decide once about render optimisation. You have
now addressed 184 findings without opening 184 files, and what remains is small
enough to be honest about.

This is the same failure as an aggregate benchmark score,
one level down: a total computed over a distribution nobody inspected, which is
also what a leaderboard throws away
when it collapses a measurement into a rank.

The same trap runs the other way for rule counts:
fourteen rules sounds like fourteen kinds of coverage. On this corpus it was
eight, and effectively two.

The check that stops this being a lie

A concentration this steep has an obvious failure mode: one file with a
repeated pattern, counted 113 times, dressed up as a finding.

So the file column exists to kill that reading. react-no-inline-functions
fires across 38 distinct files, react-render-optimization across 27. This
is a habit spread through a codebase, not one defect multiplied.

The opposite check matters too. no-inline-style fires 9 times in one file
— that row is a single site, and reading it as a codebase-wide problem would
be the same error in miniature. The column tells you which is which.

Six rules said nothing

Six of fourteen produced zero: required-attributes, react-class-to-hooks,
no-default-test-id, no-is-prefix-prop, no-kind-prop-discriminator,
no-wrapper-sub-component.

A zero is not a verdict on the rule. It is a statement about your code — and
distinguishing "this rule is dead" from "this rule is waiting" takes seconds,
because every one of them ships invalid-case fixtures that prove it can fire.
All six have them. They are waiting.

Run it on yours

The measurement is one ESLint instance and a counter, and two things about it
are load-bearing:

const eslint = new ESLint({
  overrideConfigFile: true,
  overrideConfig: [{ files: ['**/*.tsx'], plugins: { 'react-features': plugin }, rules }],
  cwd: targetDir,          // else every file is "outside of base path"
});
const files = execSync(`find ${targetDir} -name '*.tsx'`, { encoding: 'utf8' })
  .split('\n').filter(Boolean);   // a glob returned zero here
for (const r of await eslint.lintFiles(files)) {
  const fatal = r.messages.filter((m) => !m.ruleId);
  if (fatal.length) console.log('FATAL', r.filePath, fatal[0].message); // never skip these
}

My first run reported 0 findings on 100 files and all fourteen rules
zero-yield. It was wrong in the most comfortable direction. cwd defaulted to
the plugin repo, so ESLint ignored every file as outside its base path — and
the loop discarded any message with a null ruleId, which is exactly where
that explanation was written.

What caught it was a canary: a four-line component with an inline arrow and an
inline style, which must trip at least two rules. It reported zero. Nothing
from that harness was believed until the canary reported six.

Before you trust a lint number, make the tool fail on purpose.

npm install --save-dev eslint-plugin-react-features

eslint-plugin-react-features is part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

What does your top rule's file count look like — one habit, or one file?

Rename the Variable, Change the Security Verdict

Ofri Peretz — Mon, 19 Oct 2026 07:36:46 +0000

Four lines, run through my own XPath injection rule today:

xpath.select("//user[@id='" + id     + "']", doc);   // silent
xpath.select("//user[@id='" + userId + "']", doc);   // FIRES

export const QueryValidateSchema = QueryInputSchema; // FIRES
export const SchemaA             = SchemaB;          // silent

The first two are the same vulnerability. The last two are the same statement.
The only thing that changed is what the variables are called.

The heuristic

no-xpath-injection has to decide whether a value is attacker-controlled. Here
is how it decides:

const varName = inputNode.name.toLowerCase();
if (["req", "request", "query", "params", "input", "user", "search"]
      .some((keyword) => varName.includes(keyword))) {
  return true;   // tainted
}

That is the whole test. Not where the value came from — what it is spelled.

Both errors, one cause

The false positive. QueryInputSchema lowercases to queryinputschema,
which contains query and also input. Tainted. There is no XPath call in
that statement at all — it is a Zod schema being re-exported. The rule reports
an injection risk on an assignment.

The false negative. id contains none of the seven substrings, so the
value is not tainted, so a concatenation flowing into xpath.select — a sink
this rule already recognises, it is in the default xpathFunctions list — is
not reported. Textbook XPath injection, silently accepted.

The //user[...] string does contain user. It does not matter: the check
runs on the identifier, never on the literal.

One predicate, opposite failures. That is what makes this a single defect
rather than two bugs that happen to share a file.

Why this is worse than being wrong

A rule with a 70% false-positive rate is annoying and legible — you read the
findings, you see the noise, you tune it or drop it.

This is not that. This rule is right about the shape of the problem and
wrong about the input to it, which means its errors correlate with naming
conventions rather than with code. A codebase that says userInput gets
flagged everywhere. A codebase that says val, x, raw or id gets a clean
report and the same vulnerabilities.

Two teams, identical risk, opposite verdicts — and neither has any way to tell
from the output which one they are.

It also fails toward silence in exactly the case that matters. Short, neutral
identifiers are what you find in the compact, clever code most likely to be
doing something sharp with strings.

What it should read instead

The value's origin, not its spelling. Did it come from a request handler
parameter, a process.argv, a req.* member, a function boundary the rule
cannot see past? That is
taint analysis,
and it is more expensive than a substring match — which is precisely why the
substring match was written.

The honest framing is that this rule is a heuristic wearing a taint rule's
messaging. The fix is not a longer keyword list. A longer list moves the
boundary; it does not stop the verdict being a function of names.

The check that finds these

Take any rule you rely on. Write the vulnerable case. Then rename every
identifier in it to a single letter and run it again.

If the verdict changes, the rule is reading names. You now know something about
your tooling that no amount of reading its findings would have told you —
because a finding you never get is indistinguishable from a clean file, and
precision and recall measured on a corpus that shares your naming conventions
will both look fine.
It is the same reason a labelled fixture set catches what unit tests
miss:
the tests assert the rule's behaviour on the names its author chose.

This is a known class in our own tracker, with a lint check that gates new
occurrences and a documented list of the ones still outstanding. This rule is
on that list. Measured against the workspace build of
eslint-plugin-secure-coding
today — if you are on the published release, re-run before assuming.

The rule is
no-xpath-injection;
the predicate is in
its source.
Both are open, which is the only reason this article can be specific.

⭐ Star the repo if you would rather find your linter's blind spots in an article than in an incident.

eslint-plugin-secure-coding is part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

Rename the variables in your worst file to single letters. Does your linter still find the bug?

Six Rules Found Nothing. Only Five of Them Were Waiting.

Ofri Peretz — Thu, 15 Oct 2026 07:28:49 +0000

I measured fourteen lint rules against a real codebase. Six found nothing.

The tempting move is to switch those six off. The report says zero, zero looks
like dead weight, and a shorter config is easier to defend. That instinct is
wrong at least five times out of six, and here is the ten-second check that
tells you which.

A zero is three different facts

Dead. The rule cannot fire. A regression, a bad selector, an AST assumption
that stopped being true. It will report zero on every codebase forever and
nobody will notice, because zero is what a working rule looks like too.

Waiting. The rule can fire; your code does not contain the pattern. This is
the correct output and the rule is earning its keep as a ratchet — silent now,
loud the day someone writes the thing.

Unconfigured. The rule can fire, but not until you give it options. Silent
on every codebase, including the ones full of exactly what it was built to
catch.

The report renders all three as 0. The rule list does not distinguish them
either.

Ask the rule to fire

You do not have to reason about which case you are in. Every rule worth using
ships invalid test fixtures — the smallest piece of code its author swears it
must flag. Take one and lint it:

const eslint = new ESLint({
  overrideConfigFile: true,
  cwd: '/tmp',                                   // else: "outside of base path"
  overrideConfig: [{ files: ['**/*.tsx'],
    languageOptions: { parser: tsParser },       // @typescript-eslint/parser
    plugins: { 'react-features': plugin },
    rules: { 'react-features/no-is-prefix-prop': 'error' } }],
});
const [res] = await eslint.lintText(
  'interface Props { isLooped: boolean; }',
  { filePath: '/tmp/t.tsx' },
);
console.log(res.messages);

The parser line is not optional. Most of the fixtures below are interface
declarations, and the default parser cannot read them — you get a fatal parse
error where you expected the rule's verdict, and a message whose ruleId is
null. Print those; never skip them.

Fires: the rule works, your code is clean, keep it. Silent: you have learned
something the report could not tell you.

What it found

Five of the six fired immediately:

rule	fixture
`react-class-to-hooks`	`class MyComponent extends Component { }`
`no-default-test-id`	`function Card({ "data-testid": d = "card" })`
`no-is-prefix-prop`	`interface Props { isLooped: boolean; }`
`no-kind-prop-discriminator`	`interface Props { type: "checkbox" \
{% raw %}`no-wrapper-sub-component`	`function MyButton(props) { <Button {...props} /> }`

Waiting, all five. The codebase genuinely has none of it.

The sixth did not. required-attributes stayed silent on <Button /> — its
own fixture, at error, with nothing else enabled.

The one that could not fire

Reading its test file explains it:

{
  code: '<Button />',
  options: [{ attributes: [{ attribute: 'type' }] }],   // ← the part that matters
}

The rule takes its attribute list from configuration. Without options there is
nothing it has been asked to require, so it correctly does nothing. Supply the
options and the same fixture reports one error.

That is not a bug. It is worse than a bug in one specific way: a bug gets
noticed. This rule sits in a config, at error, looking enabled, and reports
zero on every codebase in the world — including one that violates it on every
line. The report cannot distinguish that from success.

Five waiting, one unconfigured, none dead. I would have guessed a different
split, and switching off "the six that found nothing" would have thrown away
five working ratchets and left the one real problem in place.

The habit

Before you delete a rule for being quiet, make it speak. If it will not, you
have found something more interesting than a finding.

The same instinct applies one level up: a lint run that reports zero is not
evidence that a tool ran. A harness of mine once reported 0 findings across 100
files because every file was silently ignored — a perfectly believable number,
and completely false. Zero is the one output that looks identical whether
everything worked or nothing did, which is why
a count means nothing without the measurement behind it
and why an aggregate hides the distribution that produced it.

npm install --save-dev eslint-plugin-react-features

eslint-plugin-react-features is part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

Which rule in your config has never once fired — and have you ever asked it to?

13 Repos Keep a Credential in Web Storage. Seven Are Governments.

Ofri Peretz — Sun, 11 Oct 2026 08:26:36 +0000

"Never put a JWT in localStorage" is the most repeated piece of frontend security advice and the least measured. So I measured it.

258,117 source files. 1,423 touch web storage — that is the denominator, found by reading source text before any rule ran. They live in 189 public repositories.

Thirteen of those repositories put a credential in storage — eleven of them a bearer token. Seven of the thirteen are government digital services.


Helsinki · `kukkuu-admin`	`localStorage.setItem(API_TOKEN, user.access_token)`
UK ONS · `eq-author-app`	`localStorage.setItem("accessToken", user.ra)`
US GSA · `srt-ui`	`localStorage.setItem('token', data.token)`
Canada · `cds-snc`	`localStorage.setItem("token", response.access_token)`
France · `betagouv` ×2	`xsrfToken`, `NATIVE_TOKEN_KEY`
British Columbia · `sso-requests`	`sessionStorage.setItem(TOKEN_SESSION, …)`

The non-government six are cloudflare-os, headlamp, mozilla_fxa, solid-playground, wix_skills and a Twilio app that stores a passcode.

The rate is the boring half

Thirteen out of 189 is about 7%. If you came expecting an epidemic, there isn't one — most code touching web storage keeps credentials out of it.

What makes seven percent interesting is where it lands. Public-sector frontends are built by rotating contractors against procurement deadlines, and they inherit whatever the OIDC tutorial did. The tutorial put the token in localStorage.

That is a mechanism, not an accusation. Two of the seven — Helsinki and the UK ONS — store a refresh token beside the access token, and that is the part that matters: an access token expires in minutes, a refresh token is a long-lived credential sitting where any injected script can read it synchronously. That is the whole argument: web storage is a trust boundary you share with every script on the page, and one DOM sink is all it takes to cross it. The six non-government hits are developer tools, playgrounds and internal consoles, where the threat model is genuinely different.

Two of the thirteen are not the mistake you think

Reading the code changes the verdict twice.

bcgov_sso-requests uses sessionStorage, not localStorage — same XSS exposure, but the token dies with the tab instead of persisting. betagouv_sante-psy stores an XSRF token, which is a different risk class entirely: it is meant to be readable by your own page, and it is not a bearer credential. That is why the count above says credential and not auth token: eleven of the thirteen are bearer tokens, and the two that are not are this XSRF token and a Twilio app passcode. bcgov is a bearer token — it is on this list for the store it chose, not for what it stores.

Counting them all as "a JWT in localStorage" would have been technically defensible and substantively wrong.

My own rule is right 13 times out of 19

no-jwt-in-storage flagged 19 repositories. I read all 39 files. Six repos are false positives, and all six fail the same way — the rule matched an identifier name rather than proving a credential:

localStorage.setItem("sessionId", sessionId);      // a demo session id
sessionStorage.setItem('app_authServer', config);  // a server URL
localStorage.setItem(AUTH_STATUS_KEY, 'success');  // the string "success"

Also flagged: a co-browse session descriptor, a telemetry session, a sandbox id, and an example user object. That is 68% precision on real source.

I am reporting it because the thirteen are only believable if you know what the instrument does when it is wrong. A field study that publishes its hit rate and not its miss rate is a marketing page.

One more, worth its own line: no-cookie-auth-tokens fired zero times across all 1,423 files. A rule that never fires in a corpus this size is telling you about the rule, not the corpus.

Run it

// eslint.config.mjs — after `npm i -D eslint-plugin-browser-security`
import browser from "eslint-plugin-browser-security";

export default [
  {
    files: ["**/*.{ts,tsx,js,jsx}"],
    plugins: { "browser-security": browser },
    rules: { "browser-security/no-jwt-in-storage": "error" },
  },
];

Expect to read the hits rather than trust them — ground truth is the hard half of any audit like this. The corpus here is an adoption scan, not a random draw from GitHub, so "7 of 13" describes what I looked at. Point it at a different corpus and the mix will move.

More of these — follow on dev.to.

Open your own repo and grep for setItem. Is the thing you find a bearer token, or did you just name a variable badly?

Related:

npm · GitHub

I Linted 14 Public AI SDK Repos. 12 Ship a Call With No Token Ceiling.

Ofri Peretz — Wed, 07 Oct 2026 07:49:42 +0000

I argued last week that an AI SDK call with no bounds is three CWEs in one missing config object. Fair question back: does anyone actually ship that?

So I linted for it. 20,004 source files across 14 public repositories, 474 of which import the Vercel AI SDK, 116 of which contain a real generation call. That 116 is the denominator; everything below is a fraction of it.

Bound	Files missing it	Repositories
output cap (`maxOutputTokens`)	103 / 116	12 of 14
request timeout	50 / 116	9 of 14
abort signal on a stream	44 / 116	7 of 14

Read the repo column, not the percentage

88.8% is the number that would travel, and it is the one I trust least. One repository, cloudflare_agents, contributes 52 of those 103 files — just over half. Percentages of files measure how a codebase is split into modules as much as how it was written.

The repo count is the robust statistic. Twelve of fourteen survives deleting any single project from the corpus. The percentage does not.

Five of the fourteen are Vercel's own

ai-elements, vercel_chat, vercel_examples, vercel_streamdown and vercel-labs_agent-eval are the SDK vendor's repositories, and they are in the findings.

That is not a gotcha — it is the mechanism. Example code is deliberately minimal; a ceiling is noise in a snippet teaching you streamText. But the minimal shape is the shape that gets copied, and it is missing the same parameter in the reader's production handler, where it is no longer noise. The omission is correct upstream and wrong downstream, which is exactly why nothing catches it.

What an unbounded call looks like in the wild

Not exotic. This is the common form:

const result = streamText({ model, messages });

The one worth showing is subtler — 302ai_302-AI-Studio builds its options indirectly:

const streamTextOptions = { ...baseConfig, ...(prompt && { system: prompt }) };
const result = await generateText(streamTextOptions);

I assumed this was a false positive: a rule cannot see into an object built elsewhere. It isn't. baseConfig sets model, messages, providerOptions and tools — and the whole 1,500-line file contains exactly one occurrence of timeout, abortSignal or maxOutputTokens between them.

The bound I threw out

The audit measured a fourth — step count — and I am not reporting it. Two reasons, either sufficient. The SDK already defaults stopWhen to stepCountIs(1), so the loop is bounded unless you raised it yourself; a rule firing there reports a non-defect. And spot-checking four of its flagged files found one that sets both stopWhen and stepCountIs and was flagged anyway.

A rule that fires on a safe default doesn't make the number bigger. It makes the other three unbelievable.

Run it on yours

// eslint.config.mjs — after `npm i -D eslint-plugin-vercel-ai-security`
import ai from "eslint-plugin-vercel-ai-security";

export default [
  {
    files: ["**/*.ts"],
    plugins: { "vercel-ai-security": ai },
    rules: { "vercel-ai-security/require-max-tokens": "error" },
  },
];

Honest limits, because n = 14 is small — and a corpus you assembled yourself is the hard half of any audit. This is an adoption-scan convenience sample, not a random draw from npm, and two directories in it turned out to be the same project cloned twice — caught by content fingerprint, since every checkout reported the same git remote. The claim is that this is what the SDK's own ecosystem looks like. It is not a population rate.

The prior sweep I tried to reuse recorded findings but no denominator and no repo list, so it could not answer this at all. A count without its denominator isn't a small result. It's not a result.

More of these — follow on dev.to.

Check the handler you shipped this week: is there a ceiling on it, or did the example not have one either?

Related:

npm · GitHub

Your LLM Call Has No Ceiling. TypeScript Is Fine With It. Three CWEs Aren't.

Ofri Peretz — Fri, 02 Oct 2026 09:10:34 +0000

generateText with a model and a prompt and nothing else is a valid call. TypeScript is satisfied. The type system has no opinion about how many tokens come back, how long it takes, or who pays for the answer nobody reads.

Three rules in eslint-plugin-vercel-ai-security fire on a call written that way, and they map to three different CWEs — 770, 400 and 404. (A CWE is a label, not a verdict — what the taxonomy actually claims — and counting CWEs is a proxy metric.) Same missing config object. Three separate ways to lose.

A note on the bound people expect: step count. The SDK defaults stopWhen to stepCountIs(1), so a tool-calling loop does not run away on its own — that hole gets opened deliberately, by raising the ceiling, not by forgetting it. The three below are genuinely unbounded when you say nothing.

1. The output with no cap — CWE-770

await generateText({ model, prompt }); // no maxOutputTokens

Why it gets written: the parameter is optional, and the happy path never needs it.

Why it survives review: output length reads as a quality knob, not a resource bound. But this is billed per token. An unbounded output is an unbounded invoice, and nothing in the diff looks like money.

Fix: set maxOutputTokens to the longest answer you would pay for — there is no correct number, only the difference between a ceiling and none. Note the rename: this was maxTokens in v4. Guidance written against v4 still reads correct in review and bounds nothing.

2. The request that never returns — CWE-400

await generateText({ model, prompt }); // no timeout

Why it gets written: fetch-shaped APIs feel like they time out. This one doesn't — timeout is optional and the SDK sets no default.

Why it survives review: staging latency is fine, so nobody asks what happens when the provider hangs instead of failing.

await generateText({ model, prompt, timeout: { totalMs: 30_000 } });

timeout has been first-class since 6.0.14 and also takes stepMs, chunkMs, toolMs. Below that, hand-roll an AbortController; the rule accepts either, but reach for the parameter first.

3. The stream nobody can cancel — CWE-404

const stream = streamText({ model, prompt }); // no abortSignal

You will file this under polish. Here is why that is wrong: the client is gone, and the server keeps generating — and billing — for a reader who will never see a token of it.

Why shutdown (CWE-404) rather than consumption (400)? The resource was acquired correctly and never released — the handle outlives the request that justified it. A release bug, not an acquisition bug.

const ac = new AbortController();
req.signal.addEventListener("abort", () => ac.abort()); // client disconnected
const stream = streamText({ model, prompt, abortSignal: ac.signal });

The pattern

All three are one defect: an allocation with no ceiling. Tokens, wall-clock, lifetime.

I don't trust an allocation whose ceiling I can't see — the same instinct that keeps me out of a position whose downside I can't draw on one page.

Classic resource-exhaustion review asks whether an attacker can make something loop forever. For an LLM call, the answer is worse — you don't need an attacker. A verbose model and one retry will do it, and the meter runs the entire time.

This is OWASP LLM10, Unbounded Consumption — the full top-10 mapping for this SDK covers the other nine. That list is a separate taxonomy from the web Top 10 — LLM10 has no A-number. For governance rather than linting, see NIST AI RMF. That is why these are security rules, not style rules. It is the move injection across nine interpreters makes too: CWE-770, 400 and 404 are the same sentence in three grammars.

The config

npm install --save-dev eslint-plugin-vercel-ai-security

Node 18+. The peer range is ESLint 8 ∥ 9 ∥ 10, so both config formats work.

// eslint.config.mjs — ESLint 9 · 10
import vercelAi from "eslint-plugin-vercel-ai-security";

export default [
  {
    files: ["**/*.ts"],
    plugins: { "vercel-ai-security": vercelAi },
    rules: {
      "vercel-ai-security/require-max-tokens": "error",
      "vercel-ai-security/require-request-timeout": "warn",
      "vercel-ai-security/require-abort-signal": "warn",
    },
  },
];

// .eslintrc.json — ESLint 8
{
  "plugins": ["vercel-ai-security"],
  "rules": {
    "vercel-ai-security/require-max-tokens": "error",
    "vercel-ai-security/require-request-timeout": "warn",
    "vercel-ai-security/require-abort-signal": "warn"
  }
}

On oxlint, add "jsPlugins": ["eslint-plugin-vercel-ai-security/oxlint"] — alpha, not under semver.

Rule docs: require-max-tokens · require-request-timeout · require-abort-signal

More of these — follow on dev.to.

Has an LLM call ever run longer in production than you expected — and what told you first, the logs or the bill?

Related:

npm · GitHub

Everyone Greps for SQL Injection. Nobody Greps for the Other Eight.

Ofri Peretz — Sun, 27 Sep 2026 19:27:57 +0000

Ask a developer to find injection in a codebase and they grep for string concatenation near a database call. They will find the SQL. They will walk past eight other interpreters on the way.

An interpreter nobody remembers is still an interpreter. Build a string, hand it to something that parses it, and you have the same bug — whether or not that parser speaks SQL.

The shape, not the syntax

The taxonomy already knew this. CWE-943 is "Improper Neutralization of Special Elements in Data Query Logic" — the parent class that SQL injection is merely the famous child of. Its siblings are the same defect aimed at different parsers.

Injection	CWE	The interpreter you forgot
GraphQL	CWE-943	the query resolver
LDAP	CWE-90	the directory filter
XPath	CWE-643	the XML path engine
XXE	CWE-611	the XML entity resolver
Template	CWE-94	the template compiler
Directive	CWE-96	the server-side include
Format string	CWE-134	the format specifier parser
Object / prototype	CWE-915	the JavaScript engine itself

Be precise about what that parent covers: the honest version is narrower than the tidy one. MITRE lists exactly four children under CWE-943 — check the Research Concepts view (View-1000) on that page — and all four are query languages: SQL (CWE-89), LDAP (CWE-90), XPath (CWE-643) and XQuery (CWE-652).

Everything else in the table is commonly mapped there, not formally filed under it. GraphQL has no dedicated CWE at all; neither do the NoSQL operator injections. And XXE, format string and prototype pollution are not siblings — they are separate defects that happen to share a blind spot, not a parent.

Eight interpreters plus SQL, in two distinct shapes — data-query injection (the CWE-943 family) and code/context injection (everything else in the table). SQL got the name people recognise. The parser inside your LDAP filter did not, and that is the entire reason it goes unaudited.

Three that fail in ways SQL does not

XXE needs no injected operator at all. Parse attacker-supplied XML with entity resolution enabled and the parser fetches local files on their behalf. There is no quote to escape, no operator to smuggle. The payload is the document.

LDAP fails silently. (uid= plus a string is a filter, and a stray ) turns an authentication check into a wildcard matching every entry in the directory. No error, no stack trace — a login that simply succeeds.

Template injection escalates further than SQL. PortSwigger's server-side template injection research showed a template engine will hand over remote code execution as readily as a database hands over rows. A templating call is not a formatting convenience; it is an evaluator.

GraphQL is the odd one, because injection is only half of it. A query the client shapes is also a cost problem — the caller, not you, decides how many nested resolvers run. That is resource exhaustion (CWE-400) wearing a query's clothes, and why a depth limit is a security control, not a performance tweak.

Why grep finds SQL and misses the rest

OWASP folds this whole family into A03. Most tooling does not, because a pattern matcher looks for a sink it has been taught — a query(, an execute(. Nobody teaches it XPathEvaluator, libxmljs, an LDAP filter:, a compile(.

That is also the honest limit of pattern matching. Seeing a + flowing into a sink does not prove the value came from a request, and it goes quiet when the concatenation happens one helper away. That gap between "looks dangerous" and "is reachable" is the whole subject of taint analysis.

What to actually do

Do not start from a checklist. Grep your own code for the constructors: XPathEvaluator, libxmljs, an LDAP filter:, a template compile(, any %s you assemble by hand. For each, ask one question — can user input reach this string?

Grep is the triage list, not the verdict: it tells you where to look, taint tells you whether it reaches.

If the answer is "probably not, but I would have to check", that is exactly the answer most people give about SQL right before they find the other eight.

Which interpreter is live in your stack right now that you have never grepped for? My money is on GraphQL.

More on how these classes get named and ranked: the CWE taxonomy and the OWASP Top 10. I write these at dev.to/ofri-peretz.

⭐ Star the repo if you would rather your linter knew about the other eight interpreters too.

One Import Moves a commander CLI to burgee. --json Still Says null.

Ofri Peretz — Wed, 23 Sep 2026 15:28:33 +0000

I changed one line in a commander CLI:

- import { Command } from "commander";
+ import { Command } from "burgee/commander";

Help, output, errors and exit codes stayed byte-identical on seven invocations. The same file also answers --schema, --mcp and completion <shell>. And --json answers "data":null.

One import describes the CLI to an agent; answering takes a return. I maintain burgee; everything below ran on commander@15.0.0 and burgee@0.11.1.

The program

Plain commander, ESM, as cli.commander.js:

#!/usr/bin/env node
import { readFileSync } from "node:fs";
import { Command } from "commander";

const program = new Command();
program
  .name("lines")
  .description("Count and rank the lines in a text file")
  .version("1.0.0");

program
  .command("count")
  .description("count the lines in a file")
  .argument("<file>", "file to read")
  .option("--skip-blank", "ignore empty lines")
  .action((file, opts) => {
    let lines = readFileSync(file, "utf8").trimEnd().split("\n");
    if (opts.skipBlank) lines = lines.filter((l) => l.trim() !== "");
    console.log(`${lines.length} lines in ${file}`);
  });

program
  .command("longest")
  .description("print the longest lines in a file")
  .argument("<file>", "file to read")
  .option("-n, --top <count>", "how many lines to show", "3")
  .action((file, opts) => {
    const lines = readFileSync(file, "utf8").trimEnd().split("\n");
    const top = lines
      .sort((a, b) => b.length - a.length)
      .slice(0, Number(opts.top));
    for (const line of top)
      console.log(`${String(line.length).padStart(4)}  ${line}`);
  });

program.parse();

The swap

npm install commander@15.0.0 burgee@0.11.1   # or: yarn/pnpm/bun add
npm pkg set type=module
cp cli.commander.js cli.js
printf 'alpha\n\nbravo charlie\ndelta echo foxtrot golf\n\nhotel\n' > sample.txt

All four work, as does require(). TypeScript's legacy node resolver cannot see the subpath. After the import swap in cli.js:

$ diff <(node cli.commander.js --help) <(node cli.js --help) && echo identical
identical

Same for count --help, both commands, a missing argument and a typo. Usage errors still exit 1; burgee's native exit 2 for "rewrite the command" does not come with the swap. Once commander leaves dependencies, the declared Node range goes from >=22.12.0 to ^20.19.0 || >=22.13.0. The swapped file ran on Node 20 and 22; only 22.12.x drops out.

What answers with no other edit

--schema: the command tree as data, a JSON Schema per command:

$ node cli.js --schema | jq -c '.commands[0].inputSchema'
{"type":"object","properties":{"file":{"type":"string","description":"file to read"},"skipBlank":{"type":"boolean","flag":"--skip-blank","description":"ignore empty lines"}},"required":["file"],"additionalProperties":false}

Errors under --json: typed, with the fix:

$ node cli.js count sample.txt --skp-blank --json
{"ok":false,"error":{"code":"commander.unknownOption","message":"unknown option '--skp-blank'","fix":"--skip-blank"}}

MCP discovery: every command becomes a tool, and an undeclared one says so instead of guessing a hint:

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node cli.js --mcp | jq -c '.result.tools[] | {name, annotations}'
{"name":"count","annotations":{"effects":"undeclared"}}
{"name":"longest","annotations":{"effects":"undeclared"}}

.effects("read_only") on count yields readOnlyHint: true. That call is a one-way door: real commander throws a TypeError.

Completions: completion <shell> for bash, zsh, fish, pwsh and fig, as static output.

Where one import stops

$ node cli.js count sample.txt --json
6 lines in sample.txt
{"ok":true,"data":null,"meta":{"provenance":{}}}

burgee's envelope wraps what an action returns. commander discards return values, so commander programs rarely write one. Under --mcp, that printed line lands on the JSON-RPC stream, where no client can parse it.

The second edit, in cli.answering.js: return the result, and keep prose off stdout when a machine asked:

+const machine = ["--json", "--mcp"].some((f) => process.argv.includes(f));
+const say = (text) => {
+  if (!machine) console.log(text);
+};
 ...
-    console.log(`${lines.length} lines in ${file}`);
+    say(`${lines.length} lines in ${file}`);
+    return { file, lines: lines.length };

$ node cli.answering.js count sample.txt --json
{"ok":true,"data":{"file":"sample.txt","lines":6},"meta":{"provenance":{}}}

Humans still see 6 lines in sample.txt. MCP tool calls get the same envelope. The argv test is crude. 0.11.1's façade has no public "machine asked?" flag yet.

Two defects, fixed in 0.11.1

Drafting on 0.9.2, I hit two defects in what the swap adds. An MCP call ignored the schema's "flag":"--skip-blank" and passed --skipBlank, which the program refused. Completions offered --no-skip-blank and --no-version, likewise refused. I fixed both in 0.11.1. The same call now answers:

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"count","arguments":{"file":"sample.txt","skipBlank":true}}}' | node cli.answering.js --mcp | jq -r '.result.content[0].text'
{"ok":true,"data":{"file":"sample.txt","lines":4},"meta":{"provenance":{"skipBlank":{"source":"flag"}}}}

Still open: an action's throw stays uncaught under --json.

What the grade covers

commander's own suite (v15.0.0, 110 files, unmodified) runs against burgee/commander next to a control on real commander. Re-run for this article: 1360 / 1360, control 1360 / 1360. That grade measures what you keep. The two defects sat in what you gain, which commander's tests cannot see.

When commander alone is the right size

On disk, commander 15.0.0 unpacks to 207,368 bytes; burgee 0.11.1 and the five sibling packages it installs, to 1,266,628. In a bundle, burgee's own lighter-than-commander gate measures not met, 1.524×. If no agent will call your CLI, commander is the smaller choice.

burgee vs commander · compatibility · source

Which command in your CLI prints something an agent currently scrapes with a regex, and what would returning it instead break?

A commander Stack Installs 70 Packages, burgee's Family 9. Like for Like, the Family Weighs 2.4 More.

Ofri Peretz — Wed, 23 Sep 2026 08:13:43 +0000

I maintain burgee, nine CLI packages, and counted them against the stack they replace, one usual package per layer:

npm i commander chalk ora inquirer string-width cosmiconfig execa signal-exit terminal-link

70 packages, maintained by 25 npm accounts. burgee's nine install 9 packages from 1 account.

That is the flattering row. Part 1 printed the rows against my plugins; same method, same rule here.

Layer by layer

Each incumbent is the first whole package in burgee's own "Replaces" column (the terminal row lists half of ansi-escapes first; with it, 66 packages), so the stack comes from my design surface, not a neutral sample. Resolved 2026-09-23, one package at a time; KB is 1,024 bytes of files, whole tree included.

incumbent	pkgs	KB	burgee family	pkgs	KB
commander@15.0.0	1	203	burgee@0.10.0	6	1169
chalk@6.0.0	1	55	roundel@0.4.3	1	76
ora@9.4.1	17	278	flagstaff@0.3.7	5	546
inquirer@14.2.2	27	1002	caique@0.4.3	3	302
string-width@8.2.2	4	36	linegauge@0.4.4	1	83
cosmiconfig@10.0.1	4	1789	seniority@0.4.3	1	149
execa@10.0.1	18	632	bellpull@0.2.3	1	96
signal-exit@4.1.0	1	75	closeout@0.4.1	1	100
terminal-link@5.0.0	6	60	paratext@0.5.4	1	91

On bytes, burgee's side is heavier in six of nine layers. Installed together, the incumbents weigh 3,851 KB; burgee, 1,577. The incumbent trees overlap (79 summed, 70 installed); burgee's overlap completely (20 summed, 9 installed).

Where that byte gap comes from

Three layers carry it, none cleanly.

cosmiconfig is 1,789 KB, and 1,702 of that is js-yaml and its argparse. seniority parses no YAML: it reads the JSON subset and refuses the rest by name. Against cosmiconfig's own test suite it passes 186 of 243.
execa has no graded drop-in. bellpull's compat row is cross-spawn, not execa.
inquirer is graded through @inquirer/core (41 of 41), not inquirer itself.

Keep only layers where burgee's drop-in scores what the incumbent scores on its own suite: commander, chalk, ora, @inquirer/core@12.0.3, string-width, signal-exit (not terminal-link: 8 of 10). 28 packages, 662 KB. burgee still installs all nine (sibling dependencies pull in the other three), 1,577 KB. Like for like, burgee is 2.4× heavier on disk, while the count stays 28 against 9, maintainers 14 against one.

The three gates burgee publishes as not met

burgee's README states nine gates; three fail their ≤ 1.0× target. I re-ran each with burgee's own fixtures:

gate	published	re-run
`burgee` bundle vs cac	2.636×	2.661×
`burgee/commander` bundle vs commander	1.514×	1.520×
cold start vs cac	1.443×	1.67–2.31×

The bundle rows agree within a percent. The cold-start re-runs, at load average above 80, read worse than burgee's published figure. Either way, not met. burgee's parity rows compare its bundles against cac, commander or yargs plus cosmiconfig, exit-hook and restore-cursor (0.282×, 0.468×, 0.531×). Those stacks include cosmiconfig, which my like-for-like rule excludes.

What "zero dependencies" means here

Six of nine declare no dependencies. burgee, flagstaff and caique depend only on those six: no dependency outside the family, which is not zero. burgee's README table says 0 runtime dependencies; the registry lists five, all siblings.

One account is also a concentration. Mid-measurement, my pipeline published burgee@0.10.0 at 05:34 UTC, then the closeout and linegauge it requires at 05:39 and 05:42; for eight minutes npm i burgee failed with ETARGET. And the family declares Node 24, where the incumbent stack's floor is Node 22.18. If you support Node 22.18, the incumbents are your option.

How to check yours

Part 1's method, plus bytes and maintainers:

cd "$(mktemp -d)" && npm init -y >/dev/null
npm i --package-lock-only <your dependencies>
node -e "console.log(Object.keys(require('./package-lock.json').packages).filter(k=>k.startsWith('node_modules/')).length)"
npm ci --ignore-scripts && node -e "let t=0;const f=require('fs'),w=d=>f.readdirSync(d,{withFileTypes:true}).forEach(e=>{const p=d+'/'+e.name;e.isDirectory()?e.name!=='.bin'&&w(p):e.isFile()&&e.name!=='.package-lock.json'&&(t+=f.statSync(p).size)});w('node_modules');console.log(t)"
node -e "const l=require('./package-lock.json').packages,m=new Set(),u=[];Promise.all(Object.keys(l).filter(k=>k.startsWith('node_modules/')).map(k=>fetch('https://registry.npmjs.org/'+k.split('node_modules/').pop().replace('/','%2F')).then(r=>r.ok?r.json():Promise.reject()).then(d=>(d.maintainers||[]).forEach(x=>m.add(x.name))).catch(()=>u.push(k)))).then(()=>console.log(m.size,'unfetched',u.length))"

Part 1 subtracted a 69-package ESLint baseline; here the shared baseline is Node, zero packages. pnpm, yarn 1 and bun resolve the same counts. The family ships often and its caret ranges float: pin all nine as tabled, or expect drift.

Run it on your CLI: how many npm accounts can ship code into your tree, and did you know that number before today?

[If the method earns a place in your release review, ⭐ star burgee.](https://ofriperetz.dev/go/gh/ofri-peretz/burgee?utm_source=devto&from=burgee-zero-dependency-cli-stack)

DEV Community: Ofri Peretz

Three of My Planned Articles Cited Numbers That Do Not Exist

What the audit found

Four ways a number goes bad in prose

Why the document could not fail

What it cost

The habit

The Most Precise Plugin in My Benchmark Scored 10.8%

Read the column the ranking hides

Why my row says 100%, and why you should discount it

The check I ran before publishing any of it

What the table is for

My Harness Reported 0 Findings on 100 Files. All 100 Were Ignored.

1. The files were outside the base path

2. The .ts files were never eligible

3. The build under test was not the build you ship

Why all three survive review

The check

My Plugin Has 14 Rules. Two of Them Found 60% of Everything.

The shape

Why the total is the wrong number

The check that stops this being a lie

Six rules said nothing

Run it on yours

Rename the Variable, Change the Security Verdict

The heuristic

Both errors, one cause

Why this is worse than being wrong

What it should read instead

The check that finds these

Six Rules Found Nothing. Only Five of Them Were Waiting.

A zero is three different facts

Ask the rule to fire

What it found

The one that could not fire

The habit

13 Repos Keep a Credential in Web Storage. Seven Are Governments.

The rate is the boring half

Two of the thirteen are not the mistake you think

My own rule is right 13 times out of 19

Run it

I Linted 14 Public AI SDK Repos. 12 Ship a Call With No Token Ceiling.

Read the repo column, not the percentage

Five of the fourteen are Vercel's own

What an unbounded call looks like in the wild

The bound I threw out

Run it on yours

Your LLM Call Has No Ceiling. TypeScript Is Fine With It. Three CWEs Aren't.

1. The output with no cap — CWE-770

2. The request that never returns — CWE-400

3. The stream nobody can cancel — CWE-404

The pattern

The config

Everyone Greps for SQL Injection. Nobody Greps for the Other Eight.

The shape, not the syntax

Three that fail in ways SQL does not

Why grep finds SQL and misses the rest

What to actually do

One Import Moves a commander CLI to burgee. --json Still Says null.

The program

The swap

What answers with no other edit

Where one import stops

Two defects, fixed in 0.11.1

What the grade covers

When commander alone is the right size

A commander Stack Installs 70 Packages, burgee's Family 9. Like for Like, the Family Weighs 2.4 More.

Layer by layer

Where that byte gap comes from

The three gates burgee publishes as not met

What "zero dependencies" means here

How to check yours

2. The `.ts` files were never eligible