856,168 differential checks later: what it actually takes to delete your dependencies

Sai Ram Dash — Fri, 04 Sep 2026 11:39:48 +0000

Somewhere around check number three hundred thousand, my test harness stopped testing my code and started testing the code I was replacing.

The check was intersects('1.2.3-beta', '*'). Mine said false. semver@7.8.5 said false. Then the harness swapped the arguments, because a harness does not know that no reasonable person swaps the arguments, and the package said true.

Same function, same two strings, opposite order, opposite answer. Intersection is symmetric in every definition of the word anybody has written down. One hundred and eighty-eight million weekly downloads disagree.

I had built the harness to find my bugs. It found one of theirs, and then handed me a problem that no amount of testing solves: I had to decide which of us was right, and there is no authority to appeal to. That turned out to be the actual work. Not the typing.

What I built

nirdep. nir (Sanskrit निर्, "without") plus dep. Say it "near-dep". It deletes your dependencies.

It is two halves that only make sense together. The first is a runtime: five modules written against the Node standard library and nothing else, standing in for eleven packages people install without thinking about it, which is chalk, strip-ansi, supports-color, ansi-styles, semver, minimatch, glob, lodash, minimist, commander and yargs. The second is a codemod: a hand-written JavaScript lexer, a scope-aware binding resolver and a byte-range patcher, so that removing a dependency is a diff you read rather than a weekend you lose.

The tool runs on its own runtime. Its help text is generated by the module that replaces commander, its colours come from the module that replaces chalk, and its version comparisons come from the module that replaces semver. That is the correctness argument, and it is a cheap one to check: if the replacements were bad, the tool would not start.

What you would normally install, and what it actually took

Normally installed	What replaced it	What it cost
chalk, strip-ansi, ansi-styles, supports-color	`runtime/colour`, 552 lines	the escape codes are the easy part; capability detection is the work, and `FORCE_COLOR` beating `NO_COLOR` is a decision rather than a fact
semver	`runtime/semver`, 1,760 lines, no regular expressions	507,316 differential checks, 72 audited disagreements, and 0.26 times the reference speed on `satisfies`
minimatch, and the matching half of glob	`runtime/glob`, 1,149 lines, no regular expressions	228,852 checks, 697 disagreements, every one bucketed by cause and pinned by count
the seventeen lodash functions people actually reach for	`runtime/collect`, 994 lines	120,000 comparisons over 8,000 seeded rounds, eleven pinned divergences
minimist, commander, yargs	`runtime/args`, 990 lines	rewritten by hand at every call site on purpose, which I will come back to

The four reference packages I could measure on disk install 2,085,975 bytes across 1,164 files. The five modules that replace them are 223,069 bytes in five files. That number is the good half of the trade. The bad half is that those five files are now mine to maintain forever, and the README says so in the same paragraph, because a write-up that reports only the good half is an advertisement.

The rule that shaped everything

CVE-2022-25883 was a ReDoS in node-semver's range parser: hand it a range from an untrusted source and it hangs. CVE-2022-3517 was the same bug class in minimatch's brace expansion, inside the package semver itself depends on.

Replace either one with my own regular expression and I would have shipped the same bug class with my name on it and called it progress. So the rule for both modules was: no regular expressions at all. Every scanner is a loop over character codes, and the matcher is two nested state-set simulations, one over path segments and one over the characters inside a segment. Work is positions times tokens. Backtracking is absent rather than patched.

Claims like that rot, so the test does not trust me. tests/repo/no-regex.test.mjs lexes both files with the project's own lexer, because / is division, a comment and a regular expression, and only a tokeniser knows which one it is looking at. It fails if a single regexp literal survives, and it enforces a token floor, so a refactor that quietly deletes the matcher cannot pass by having nothing left to check.

The price is on the invoice. satisfies runs at 0.26 times the reference, it is in bench.json, and I am not going to pretend a state machine beats a compiled regex at its own game. Two of the five went the other way and I did not plan either: the no-regex matcher runs at 1.37 times minimatch, and cloneDeep at 1.40 times lodash. I would not have believed either claim without the numbers file, which is roughly why the numbers file exists.

The difficulties, in the order they hurt

The divergence audit was the project. 507,316 checks against semver: 507,244 agreed and 72 did not. Every one of the 72 was then re-checked against the reference package's own satisfies, and every one came back the same way, which is that the package contradicts itself. Fifty-six were intersects cells and sixteen were subset. Two more were crashes there and answers here.

glob was 697 disagreements out of 228,852, and not one of them is a shrug. print accounts for 576 of them, because their [[:print:]] compiles as though it were [[:cntrl:]]. nonascii accounts for 91, because my POSIX classes are ASCII tables, which is a stated limit: 中 is not [[:alpha:]] here. partial is 18 and brace is 12. The counts are pinned, so a new disagreement lands in a bucket called unknown and turns the suite red.

The goal was never "it agrees with the package". The goal is that every place it does not agree is either a repaired bug or a decision somebody wrote down. A difference you cannot name is a gap.

lodash taught {} a new trick. Try _.set({}, 'toString.polluted', 'yes'). A blocklist of __proto__, constructor and prototype does not save you, because toString is not on the list. The walk follows an inherited property, materialises it on the object, and writes there. From then on every object in the program carries it, and _.pick({}, 'toString') on a completely unrelated empty object hands the value straight back.

_.set({}, 'toString.polluted', 'yes');   // no error, nothing on the blocklist

({}).toString.polluted                   // 'yes', on every object in the program
_.pick({}, 'toString')                   // hands it back from an unrelated empty object

The fix is not a longer list, it is a rule: a deep write never follows a property the object does not own. Which means my module behaves differently from the package it replaces, which means it belongs in the documented divergence list rather than being quietly described as compatible.

lodash's dist runs in sloppy mode and an ESM module does not, so writes to frozen slots that silently did nothing there throw here. Every write now goes through Reflect.set and every delete through Reflect.deleteProperty: an impossible operation declines quietly with a lodash-compatible return value, and a dangerous one still throws. My first attempt swallowed the coercion complaints as well, which felt tidy and took the divergence count from three to eighty-seven. When the count goes up, put the change back.

Node ships no parser, and the honest door costs five hundred times the cheap one. A codemod that writes a file it has not proved parses is a tool you use exactly once. There are three ways to reach a JavaScript parser without installing anything: vm.Script, which rejects the word export and so cannot see modules at all; vm.SourceTextModule, which needs a flag, and whose SyntaxError carries no position, so a failure has to be re-run through node --check purely to learn which line broke; and spawning process.execPath with --check --input-type=module. The vm door costs 0.025ms and a function call. The spawn costs a process. Only the expensive one can see a module and tell you which line broke.

Measured over 300 files: 8ms through the lexer pre-gate, 4,095ms through Node's real parser, one process per file. I kept the 4,095ms. The lexer is a free pre-filter that catches the obvious failures, and the spawn is the verdict. bench.json prints both numbers side by side, so the price of being careful is visible rather than argued about.

const of = f(x) cost me an afternoon. My binding resolver ends a declarator's pattern at of or in, because that is the shape of a for-of head. So const of = f(x) ended before it began, no binding was recorded, and every later call to of(item) was filed as a global. A rename would have missed every one of those sites and the diff would have looked fine.

const of = f(x);   // pattern ends at `of`, so no binding is recorded
of(item);          // filed as a global, and a rename never touches it

What caught it was not a unit test of the resolver. It was a property test over the whole repository: every name the resolver leaves unresolved must be a real global in the running Node. Three leaked names, and the suite pointed straight at them. If I keep one habit from this project it is that one, because example-based tests only check the cases you already thought of.

The proof had to stay too blunt to fool. tools/verify.mjs reads every .mjs file in the repository, extracts import specifiers by six different syntaxes, and fails unless every single one resolves to a relative path or to something module.isBuiltin recognises. It deliberately does not read package.json. An empty manifest says nobody declared a dependency; this says nobody imported one.

$ node tools/verify.mjs
nirdep -- zero-dependency proof
generated by: node tools/verify.mjs
node: v22.23.2   platform: linux

1. Manifest
PASS  package.json dependencies is empty (0 entries)
PASS  package.json devDependencies is empty (0 entries)
PASS  package.json peerDependencies is empty (0 entries)
PASS  package.json optionalDependencies is empty (0 entries)
PASS  no node_modules directory in the repository
PASS  no lockfile entries beyond the root package

2. Every import in the artifact resolves to a Node builtin or a relative path
PASS  540 import specifiers checked across 105 files

3. The standard library we actually use
      node:assert/strict   node:child_process   node:crypto   node:fs
      node:module          node:os              node:path     node:test
      node:url             node:util            node:vm       node:zlib
      12 builtin modules, 0 packages

RESULT: zero third-party runtime dependencies.

It is also stupid on purpose, so it flags import-shaped text inside comments, strings and regular expression literals. The cost is real and slightly ridiculous: test fixtures live in JSON rather than in source, doc comments never write the word import followed by a quote, and one test builds its quote with String.fromCharCode(39). Adding an ignore pragma would have taken thirty seconds and destroyed the only thing the file is for. A blunt instrument nobody can fool is worth more than a clever one that can be.

The part I am proudest of is a refusal

Of the eleven packages, five are rewritable and six are advise-only, and a test asserts that the rewritable list stays shorter than the replaceable one, so the flattering ratio cannot quietly improve.

minimist is advise-only even though runtime/args replaces it outright. minimist hands back a flat bag of whatever it happened to find; parse wants a declared spec. A codemod that treated those two as the same shape would print green and ship a broken program. supports-color, ansi-styles, commander, yargs and glob are advise-only for the same reason: the replacement exists, the shape differs, and no machine should be guessing at a call site.

You can watch this land. The worked example declares six dependencies and installs twenty-three. nirdep apply rewrites four files, and then the project will not start, because Cannot find package 'minimist' is the correct output at that point rather than a bug. The walkthrough shows that error instead of cutting to the working version.

One more refusal, and it is the one people ask about: nirdep never edits your package.json. A tool that rewrites your manifest on your behalf is a tool you cannot trust with your imports.

The one number that changed how I read tooling

Removing glob from the example takes seven packages out of the tree. chalk takes six, semver takes three, lodash one, minimist one, and minimatch takes zero, because glob keeps minimatch alive.

Add those up and you have accounted for eighteen of the twenty-two installed names. Remove all six together and all twenty-two go. The four that appear in nobody's column are minimatch and its own three children, shared by two dependencies, so owned alone by neither.

Blast radius is a subtraction, not a sum: everything reachable from every root, minus everything still reachable from the roots that are staying. Any tool that reports it as a sum is overselling, and the honest version of that report is a worse-looking number.

That minimatch row saying "removing it takes 0 packages out of the tree" is my favourite line in the whole output. It is the tool declining to round in its own favour.

The numbers

Number	What it counts
0	third-party packages in the import graph, proved by reading imports rather than the manifest
12	Node builtins the entire project resolves to
634	tests in 55 files, on `node:test`, with no test dependency
3,593	conformance cases across the eleven packages replaced
856,168	differential checks against the packages being replaced
769	disagreements found on semver and glob, every one audited and given a cause
14,287	lines in 42 files under `src/`
2	builds, byte for byte identical, both hashes published

What seventy-two hours felt like

Writing the modules was maybe a third of it. The rest went on the harnesses, and on the arguments the harnesses started.

That ratio is the thing I did not expect. You do not get a replacement by writing a replacement. You get one by writing something whose job is to prove your replacement wrong, running it a few hundred thousand times, and then sitting with the disagreements one at a time until each has a name and a reason. Most of them will be your fault. A few will not be.

A dependency is a promise about a stranger's future behaviour, and you cannot audit a promise. That is not a moral failing on anybody's part, it is just what the arrangement is. What you can audit is code you are able to read. Replacing a package does not delete the work, it moves the work somewhere your name is on it, and the only honest reason to do that is if you would rather own the bug than wait for the advisory.

The 72 disagreements are the part I keep thinking about. Correctness is not really a property of code. It is a property of an argument somebody is prepared to make out loud. A package with 188 million weekly downloads has never had to make that argument about intersects, because nobody swaps the arguments. I had to make it seventy-two times in one afternoon, and writing those arguments down turned out to be worth more than any of the code they were about.

Repository: https://github.com/ewwhardik/nirdep
Playground, one HTML file, no network requests: https://ewwhardik.github.io/nirdep/
Worked example, before and after: https://github.com/ewwhardik/nirdep-example

Published by Nastik AI. Developed by Sai Ram Dash (Hardik).

DEV Community: Sai Ram Dash