DEV Community: Ofri Peretz

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)

55 Places My Code Predates the Language. All Auto-Fixed.

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

const latest = baseline[baseline.length - 1] ?? null;

Nothing is wrong with that line. It passes review, ships, and works. It is also how you wrote JavaScript before 2022, and I have written it a thousand times since.

I ran four modernization rules over 389 .ts/.tsx files across four of my own repos. 55 findings in 36 files — and every single one carried an autofix. After --fix, the remaining count was zero.

The two that fired

prefer-at — 11 findings. The end-of-array idiom, mechanically rewritten:

// before
const latest = baseline[baseline.length - 1] ?? null;
for (const a of accrual[accrual.length - 2].articles) {
  /* … */
}

// after --fix
const latest = baseline.at(-1) ?? null;
for (const a of accrual.at(-2).articles) {
  /* … */
}

prefer-template-literal — 44 findings:

// before
String(res.stderr || res.stdout || "claude exited " + res.status);

// after --fix
String(res.stderr || res.stdout || `claude exited ${res.status}`);

Why this survives review forever: a reviewer's job is to reject broken code, and none of this is broken. arr[arr.length - 1] is correct in every runtime that ever existed. The only thing that can flag it is a tool that knows what year it is.

The two that found nothing

no-instanceof-array and prefer-event-target returned 0 findings across all 389 files.

A rule that never fires is not broken — it is a rule for a pattern you do not have. instanceof Array breaks across realms; if you have never hit it, silence is correct. The failure mode to fear is the opposite: I have a rule elsewhere that flags every .map() in JSX, 476 findings of noise. Yield tells you nothing about quality on its own — the same trap as counting rules instead of measuring them.

Lint as codemod, not as style

Most lint rules ask you to decide something. These ask you to apply something — the semantics are identical and the fixer is exact.

You do not triage 55 findings — you run the fixer once, read the diff as one commit, and the rule holds the line. A migration plus a ratchet, the same shape as an autofix turning a hardcoded secret into a one-command repair.

Check the diff, though — "auto-fixable" means exact, not invisible, and there are two catches. .at() is typed at(index: number): T | undefined, while arr[arr.length - 2] is typed T, so a chained access can stop compiling: my accrual.at(-2).articles above is TS2532: Object is possibly 'undefined' under --strict. The ?? null on the first example absorbs it; a bare chain needs a guard. And .at() is ES2022 — Node 18+ and any 2023+ browser are fine, older targets need a polyfill.

The config

// eslint.config.mjs
import modernization from "eslint-plugin-modernization";

export default [
  {
    files: ["**/*.ts", "**/*.tsx"],
    plugins: { modernization },
    rules: {
      "modernization/prefer-at": "error",
      "modernization/prefer-template-literal": "error",
      "modernization/no-instanceof-array": "error",
      "modernization/prefer-event-target": "error",
    },
  },
];

npm  install --save-dev eslint-plugin-modernization   # npm
yarn add     --dev      eslint-plugin-modernization   # yarn
pnpm add     --save-dev eslint-plugin-modernization   # pnpm
bun  add     --dev      eslint-plugin-modernization   # bun

npx eslint . --fix

Measured against 3.1.2, peer range ^8.40.0 || ^9.0.0 || ^10.0.0, Node 18+. prefer-template-literal does not exist before 3.x, so an older install rejects the config. ESLint only.

All four at error is safe for these findings, but be precise why: in 3.1.2 only prefer-at and prefer-template-literal carry a fixer. All 55 findings came from those two, which is why --fix emptied the list — not because the plugin is 100% auto-fixable:

node -p "Object.entries(require('eslint-plugin-modernization').rules)
  .map(([k,r]) => k + ': ' + (r.meta.fixable || 'no fixer')).join('\n')"
# no-instanceof-array: no fixer
# prefer-at: code
# prefer-event-target: no fixer
# prefer-template-literal: code

Run it against the published package: a monorepo symlink resolves to unreleased source and answers a different question. prefer-event-target gains a fixer after 3.1.2.

Rule docs · npm.

Numbers measured 2026-08-12 against four repos I own — my code, not a public corpus, so treat 55 as a shape.

Re-run 2026-09-04 over the 189 .ts/.tsx files of this blog's public apps/blog/src, plugin at 3.1.2: 8 findings in 6 files — six prefer-at, two prefer-template-literal. Three weeks after the codemod, the old idiom had crept back eight times. That is the argument for leaving the rules at error.

Two guards on it. The harness reports unmatched: 0, so all 189 files were configured — an earlier run returned a confident 0 that was 189 files matching no config. And on that tree the same day, the noisy rule above returns 110: yield is not quality.

What's the oldest idiom still alive in your codebase — and is it there because it's correct, or because nothing ever flagged it?

My Benchmark Judged Five Models Against a Threshold Built for Three

Ofri Peretz — Thu, 17 Sep 2026 08:25:12 +0000

I went looking for a missing Bonferroni correction in my own benchmark. I found something worse on the way: the one significance test I did have was a dictionary.

const criticalValues = { 1: 3.841, 2: 5.991, 3: 7.815 };
const significant = chiSq > (criticalValues[df] || 5.991);

Three degrees of freedom in the table. Anything else falls through the || to 5.991 — the df=2 threshold. df here is models.length - 1, so the moment I compared five models, every verdict was measured against a bar meant for three.

Both predicates, on six statistics inside that gap:

χ²	df	old verdict	true p
7.0	4	significant	0.1359
8.0	4	significant	0.0916
9.0	4	significant	0.0611
7.0	5	significant	0.2206
10.0	5	significant	0.0752
12.0	6	significant	0.0620

Six for six — guaranteed: I chose points inside the gap. A probe shows the mechanism, not how often it fired. One of them has a true tail probability of 0.22 and the old predicate called it p < 0.05.

It fired once, and got the right answer

I went through every stored result. Eleven run files, three
of them carrying a chi-squared verdict, and exactly one lands in the gap:

{ "chiSquared": 18.43, "df": 4, "pValue": "< 0.05", "significant": true }

Judged against 5.991 instead of the 9.488 its four degrees of freedom
required. And it was right anyway — the true p is 0.001017, comfortably
significant on any threshold.

That is the whole problem in one row. The instrument was broken, the answer was
correct, and the output could not tell you which. A wrong method that returns
the right answer is not a near miss; it is a bug with no symptom — the kind
that stays.

The error had a direction

The table cannot make a real result disappear. The fallback is lower than every threshold it stands in for, so the mistake only ever converts noise into a finding. It never withholds one.

That asymmetry is the tell. A bug that fails randomly is a bug. A bug that fails exclusively in the direction that flatters your results is a bug you were never going to notice: every time it fired it told you what you hoped to hear.

Why it survived review

Because it looks like rigor. A table of critical values is textbook furniture, and the numbers are right — 3.841, 5.991 and 7.815 are correct for df 1, 2 and 3. Nothing in the diff is wrong. The defect is the || 5.991 — eight characters that turn "I don't know" into a confident answer.

It reads as harmless. I found the same function in a second runner where someone had already met this problem and fixed it — two more rows, 4: 9.488, 5: 11.07, behind the same || 5.991. The cliff moved from df≥4 to df≥6 and got harder to see, because the table looked more complete. Extending a lookup table is not fixing a lookup table.

The fix is arithmetic, not a bigger dictionary

The tail of a chi-squared distribution is a function. Compute it:

export function chiSquaredPValue(chiSq, df) {
  if (!(chiSq >= 0) || !(df >= 1)) return 1;
  return upperGamma(df / 2, chiSq / 2); // regularized incomplete gamma
}

That is the interface, not the implementation: upperGamma and a Lanczos log-gamma are not exported, so read it rather than paste it. It lives in benchmarks/lib/stats.ts on the branch carrying this fix (ofri-peretz/eslint#952), and npm --prefix benchmarks run stats:check runs it in a second. It reproduces 3.841, 5.991 and 7.815 to three decimals — and 9.488 and 11.07, which the table never had.

Then the check, which matters more than the fix. It asserts the rule, not the absence of one bad number: for a fixed statistic, more degrees of freedom must yield a larger p-value. That is the relationship the fallback inverted, so it fails loudly on the old code and passes on the new. A fix without a check that would have caught it is a fix you get to make twice.

The uncomfortable part is not that my benchmark had a bug. It is that the bug sat in the code for four months, judging every verdict against a bar meant for three, and the one time it mattered it agreed with me.

Foundations: what a p-value actually claims, statistical power, composite scores.

More of these — follow on dev.to.

If your own harness prints a p-value, did you check it was computed rather than looked up?

Your ESLint Plugin Installs 205 Packages. 69 Are ESLint.

Ofri Peretz — Sun, 13 Sep 2026 08:48:55 +0000

npm i -D eslint-plugin-import installs 205 packages.

That number is true and almost useless, which is the problem with every dependency-weight argument I have read. 69 of those packages are ESLint itself. Since npm 7, peer dependencies install automatically, so any plugin declaring eslint as a peer drags the entire linter into the count — and every plugin should declare it that way.

So I measured the baseline first, then subtracted it.

What each plugin actually adds

Resolved with npm install --package-lock-only into an empty project, one plugin at a time, on 2026-08-12. Bare eslint alone resolves to 69 packages — that is the zero point.

plugin	tree	adds	direct deps
eslint-plugin-import	205	136	19
eslint-plugin-react	204	135	18
eslint-plugin-jsx-a11y	194	125	15
eslint-plugin-unicorn	110	41	20
eslint-plugin-sonarjs	83	14	13
eslint-plugin-n	80	11	8
eslint-plugin-promise	70	1	1

Now look at the two columns on the right together, because they do not agree.

eslint-plugin-promise declares one direct dependency and adds one package. eslint-plugin-unicorn declares twenty and adds 41. eslint-plugin-sonarjs declares 13 and adds 14. But eslint-plugin-import declares 19 and adds 136 — seven per declared dependency, because its dependencies have dependencies.

Direct dependency count does not predict install weight. It is the number people quote, including me before I measured it, because it is the one visible on the npm page without resolving anything.

The number you actually install

Nobody installs one plugin. A conventional React setup:

npm i -D eslint eslint-plugin-react eslint-plugin-jsx-a11y eslint-plugin-import

228 packages. Not 69 + 135 + 125 + 136 — the trees overlap heavily and npm dedupes them, so the sum is far less than the parts. That is the other half of why per-plugin numbers mislead: they are neither additive nor independent.

Where mine land

I maintain a plugin suite, so here is my own row, measured identically:

plugin	tree	adds	direct deps
eslint-plugin-react-features	71	2	1
eslint-plugin-modernization	71	2	1
eslint-plugin-browser-security	71	2	1
eslint-plugin-import-next	97	28	2

Two packages: one shared internal toolkit, which itself has zero dependencies, plus the plugin. import-next adds 28 because it carries a real resolver — that is the trade it makes for being much faster.

I am not the leanest here and I want to be precise about that: eslint-plugin-promise adds one package and I add two. If dependency weight is your only axis, promise is the leaner choice.

One more honest reading of the table. eslint-plugin-security resolves to 3 packages total — the smallest number on this page by a wide margin. It does not declare eslint as a peer dependency at all, which is why the 69-package baseline never appears, and it is the plugin I have argued elsewhere is unmaintained. A small tree is not a proxy for a healthy package. It can just mean the package stopped changing.

How to check yours

mkdir /tmp/w && cd /tmp/w && npm init -y >/dev/null
npm i --package-lock-only <plugin>
node -e "console.log(Object.keys(require('./package-lock.json').packages).filter(k=>k.startsWith('node_modules/')).length)"

--package-lock-only resolves the graph without downloading anything, so it runs in about a second. Measure bare eslint first, subtract, and compare like with like. Then measure the union you actually install, because that is the only number that reaches your node_modules.

Every figure above was resolved on 2026-08-12 and will drift as these packages release. Re-run the four lines above rather than citing mine.

Re-run on 2026-09-04, all fourteen numbers on this page came back identical — the 69-package baseline, every plugin tree, and the 228-package combined install. Three weeks of ecosystem churn moved none of them, which is itself the finding: these trees are stable because the packages at the top of the table are not releasing.

Run it on your config — what's the gap between the packages you asked for and the packages you got?

[📦 npm i -D eslint-plugin-react-features — two packages, and you can check that number with the four lines above before you install it. If it earns its place in your CI, ⭐ star the repo.](https://ofriperetz.dev/go/npm/eslint-plugin-react-features?utm_source=devto&from=eslint-plugin-dependency-weight)

eslint-plugin-react-features is part of the Interlace ESLint ecosystem — every tree in the table above is measurable the same way. Source on GitHub · Follow: Dev.to/ofri-peretz

The 3 Most-Installed ESLint Plugins Went Quiet in 2025

Ofri Peretz — Sat, 12 Sep 2026 08:31:59 +0000

Pick the maintenance signal you can get in one second: days since the last release.

I pulled it from the npm registry for 18 ESLint plugins on 2026-08-12. The three with the deepest install base are the three that have gone quietest.

plugin	days since release	releases in 12mo
eslint-plugin-jsx-a11y	655	0
eslint-plugin-react	495	0
eslint-plugin-import	417	0
eslint-plugin-promise	107	1
eslint-plugin-security	61	2
eslint-plugin-sonarjs	28	9
eslint-plugin-unicorn	8	17
eslint-plugin-n	3	12
eslint-plugin-jest	0	35

Nine of the eighteen I measured shipped nothing at all in the last twelve months. Nearly two years of silence on the plugin that half the accessibility tooling in React depends on.

Dormant is not dead

Before drawing the obvious conclusion, the honest caveat: a plugin that stops releasing may simply be finished. jsx-a11y encodes WAI-ARIA rules. ARIA does not change every quarter. A stable spec produces a stable plugin, and "no releases" is the correct output for a package with nothing left to do.

So days-since-release is a prompt, not a verdict. Three signals actually separate finished from abandoned, and all three are free:

1. The npm deprecation flag. eslint-plugin-standard carries one. That is the maintainer telling you directly, and it is machine-readable — no interpretation required.

2. Supersession. eslint-plugin-node last shipped 2,328 days ago — over six years — because it was replaced by eslint-plugin-n, which shipped 3 days ago. One of those numbers is alarming and the other explains it. A rename is invisible to anyone reading only the old package's page.

3. Whether it still works on your ESLint. This is the one that matters and the one nobody checks until it breaks. A plugin frozen before flat config became the default is not "stable," it is on a countdown.

The genuinely dead tier

Sorted by silence, these are the ones where no reading rescues the number:

eslint-plugin-scanjs-rules      3,296 days   (9 years)
eslint-plugin-node              2,328 days   superseded by eslint-plugin-n
eslint-plugin-standard          2,088 days   npm-deprecated
eslint-plugin-flowtype          1,748 days   Flow itself receded
eslint-plugin-xss               1,507 days
eslint-plugin-security-node       951 days

Every one of these still installs cleanly today. npm will not warn you, your lockfile will not warn you, and a config that references them keeps passing — because a plugin whose rules never fire looks exactly like a codebase with no problems. That is the same failure shape as a CI check that was disabled rather than failing: silence reads as success.

The one that came back

eslint-plugin-security is the interesting row. It went 3.0.1 in June 2024 → nothing for 20 months → 4.0.0 in February 2026, and shipped again in June. If you had measured it in January you would have called it abandoned, correctly, and been wrong by March.

That is why a claim needs an expiry date rather than a verdict. "Unmaintained" is not a property of a package. It is a measurement with a date on it, and this one moved.

Measure your own config

Do not use time.modified for this. It is the obvious field and it is the wrong one: npm bumps it on any metadata change, so deprecating a package or transferring ownership makes a dead package look freshly touched. eslint-plugin-flowtype reports time.modified of 2026-01-24 — seven months ago, apparently maintained. Its last actual release was 2021-10-29. That is the 1,748-day row above, and the gap between the two fields is 1,548 days of false reassurance.

Read the publish date of the current version instead:

npm view <plugin> version                  # e.g. 8.0.3
npm view <plugin> time.8.0.3               # the date that version shipped

Or resolve the whole set at once:

node -e "for (const p of Object.keys(require('./package.json').devDependencies ?? {})) \
  fetch('https://registry.npmjs.org/'+p).then(r=>r.json()) \
    .then(j => console.log(p, j.time[j['dist-tags'].latest].slice(0,10)))"

Then apply the three checks above to anything past a year. Most will be fine. The point is knowing which ones you are betting on — eslint-plugin-import at 417 days is a dependency worth having an opinion about, given what it does on every lint run.

All figures resolved from the npm registry on 2026-08-12 and already drifting — eslint-plugin-jest was at 0 days when I measured it. Re-run the one-liner rather than citing mine.

Source at github.com/ofri-peretz/eslint · packages at npmjs.com/~ofriperetz · more at dev.to/ofri-peretz.

What's the oldest plugin in your lockfile — and did you know it before you looked?