DEV Community: Sai Ram Dash

[Boost]

Sai Ram Dash — Thu, 01 Oct 2026 05:04:48 +0000

Sai Ram Dash

Oct 1

One SQL Update Reopened a Closed Hackathon. The Checker Still Exited 0.

#dogfoodhack #sairamdash #hardikdash #hackathonraptors

13 min read

One SQL Update Reopened a Closed Hackathon. The Checker Still Exited 0.

Sai Ram Dash — Thu, 01 Oct 2026 04:41:17 +0000

A closed hackathon accepted a submission with HTTP 200.

The fixture event was closed. The official checker tried to submit to it anyway, and the server was supposed to refuse. This was meant to be the boring part of Manak, the hackathon judging portal I built.

The cause was in my demo seed. While opening community voting, I had used one parameter for two deadlines:

`update event set voting_mode = 'open', voting_open_at = :o,
 voting_close_at = :c, voting_credits = 100,
 submissions_close_at = :c where id = :e`

// The same :c binding served both deadlines.
c: systemClock.now() + 3600000 * 48

Two deadlines, one binding. The closed fixture event got another 48 hours, the stored window allowed the submission, and the server did what its data told it to. I had written the data.

Historical regression and repair. Reusing a deadline binding changed which submissions the event allowed. Current seed implementation.

Six probes passed. The closed-event probe failed, taking the first-tier acceptance gate with it. The checker still exited with code zero. The report contained the answer; the process status did not carry it. An old green report and a successfully completed command were both poor substitutes for reading what the running demo had actually done.

I changed the seed to read the imported submission deadline and bind it separately. The completed fixture showcase keeps its voting window closed too. The corrected official receipt reads:

T1  gallery is public ................. PASS
T1  project from fixtures shown ....... PASS
T1  closed event refuses submissions .. PASS
T2  judge sees own scores ............. PASS
T2  judge cannot see peer scores ...... PASS
T2  participant blocked ............... PASS
T2  csv export works .................. PASS

claimed T1 T2 T3 T4, verified T1 T2
note: claimed but not verified: T3 T4

Seven passing probes, two verified tiers. Both belong in the description of that result.

An interactive demo needs its own event state. Its convenience settings cannot rewrite the canonical fixture's rules. That small repair also explains the larger build: a judging system has to preserve the conditions under which a decision is valid. The first condition I had broken was the deadline.

Build the event around the score

Manak—मानक, “standard”—takes an event from submissions to signed awards. Organizers define tracks and a versioned weighted rubric. Teams submit projects. Eligible judges receive assignments, keep private drafts and submit scores. Organizers publish a frozen result revision, record award decisions and issue signed certificates.

That sequence became the useful unit of design. Calculating a score is one stage. Getting the right evidence into it, deciding when it becomes official and retaining what that decision meant are the surrounding stages.

The runtime uses Node's HTTP, SQLite, crypto and test APIs, native TypeScript stripping and server-rendered HTML. There are zero runtime npm packages; TypeScript and Node type definitions remain development dependencies. The main forms work without browser JavaScript. The enhanced editor and offline verifier use it.

A declared command registry feeds capabilities, validation and OpenAPI, although some transport routes sit outside it. I also wrote the request schema layer: the same field declarations drive validation, JSON Schema and form rendering. URL-encoded forms can opt into converting strings to numbers; JSON clients must send typed numbers. Unknown fields are refused. A form's "5" and a JSON client's 5 need a deliberate contract before either reaches a score column. The package graph is small. The amount of application behavior I own is less cooperative. Request schema, stack and setup.

A spreadsheet leaves deadlines, permissions and publication snapshots to a process. A live ranking page makes the latest ordering easy to see, but still needs a rule about what later edits do to an announced result. I put those obligations into explicit application state. The cost is more transitions, migrations and tests. The benefit is being able to ask the code where a rule is enforced.

Approach	What it makes easy	What still needs an owner
Spreadsheet and manual process	Inspecting and changing scores	Permissions, deadline enforcement, snapshots and award records
Live ranking page	Showing the latest ordering	Deciding whether later edits should move a published result
Manak's explicit workflow	Enforcing transitions and retaining decision context	Application state, migrations, tests and operational maintenance

Design tradeoffs, not a benchmark or a claim about every competing product. Each approach leaves a different part of the judging process for someone to maintain.

This is why the portal is larger than a score form and a sort. Team ownership, a judge's conflict, a rubric edit and an organizer's correction all change which actions should be possible. Giving each one a visible state costs code, but it also gives the next stage something more precise than an assumption to work with.

Put the rule where the write happens

My governing rule is: if breaking a rule would invalidate a decision, enforce it at the write boundary and keep the evidence needed to inspect it later.

This is the database trigger for submission timestamps:

create trigger project_submission_window before update of status, submitted_at on project
when new.status = 'submitted' and (new.submitted_at <
  (select submissions_open_at from event where id = new.event_id) or new.submitted_at >=
  (select submissions_close_at from event where id = new.event_id))
begin select raise(abort, 'project submission timestamp outside event window'); end;

It checks the supplied timestamp against the stored window. It cannot establish that the window itself is correct. Once my seed moved the deadline, the trigger had a perfectly valid reason to allow the submission. Constraints, authorized state transitions and fixture setup have separate jobs; the opening bug crossed the gap between them. Invariant triggers.

Refusals needed a boundary too. A denied write should leave no audit-ledger effects. My isolation check sends requests through actual sockets: 102 operations, six witnesses and two renderings make 1,224 requests. It records 674 refusals, including 418 writes, with zero ledger appends from refused requests and zero chain breaks.

The test also rejects an easy false positive. A parser error or rate-limit response cannot stand in for an authorization refusal. Otherwise I could congratulate the permission check for a request that never reached it. The proof covers the declared command matrix; transport exceptions remain outside that coverage. Isolation proof.

Collect evidence the model can compare

Judges see subsets of projects. Scheduling therefore changes what the statistical model can know.

If two panels judge disjoint groups, a low-scoring panel might be stricter, or its projects might be weaker. Scores alone cannot identify the relative panel offsets. No amount of arithmetic supplies the missing connection.

The scheduler starts with the most constrained projects and assigns work to eligible judges carrying lighter loads. It then uses augmenting paths to fill slots that a local placement can leave stranded. An existing assignment can move to make room for another, provided every edge remains eligible and every capacity still holds. If the requested coverage is impossible, the shortfall stays visible. Quietly relaxing a conflict would make the schedule look complete by changing what “complete” meant.

For small cases, I can give the scheduler an unusually stubborn reviewer: enumerate every answer. The test covers all 512 eligibility graphs for three projects and three judges, targets of one and two reviews, and capacities of [1, 2, 1]. It compares the result with every admissible edge subset. This is practical at that size and avoids making the oracle another copy of the scheduling algorithm. It establishes those small cases, without pretending to prove every possible event. Scheduler, completeness test.

Collecting the right evidence also means keeping working state out of it. The loader selects submitted ballots for the resolved published rubric version and excludes memberships whose evidence has been excluded. Drafts cannot move the fit. A submitted ballot must cover every criterion, and scores retain their rubric version. Once a version has scores, database triggers reject adding, editing or deleting its criteria. Otherwise a later rubric edit could change the meaning of an earlier judgment without the judge touching it. Evidence loader.

Make the model compete with simpler answers

The rubric model fits:

score(project, judge)
  = grand mean + project effect + judge offset + residual

It also estimates each judge's scale and shrinks it toward one. A judge who gives every project the same score carries little ordering information. Dividing by a tiny spread should not turn that into a powerful opinion. Scale floors and information weights handle that case. Model implementation.

The machinery then owes a comparison. I tested raw means, per-judge z-scores and the fitted model against planted rankings in synthetic events. The displayed regimes quantize and clamp scores to 1–5. The full sweep covers 59 configurations over 20 seeds, or 1,180 event runs.

The balanced case uses the production scheduler. The correlated cases deliberately substitute assignments in which judges are grouped by leniency and projects increasingly prefer one judge cohort. Planted project quality is generated independently. The experiment changes which judge groups see which projects; it does not establish a true ranking for a real event.

Assignment regime	Raw mean	Per-judge z-score	Fitted model
Balanced	0.7865	0.8369	0.7935
Mildly correlated	0.7630	0.8564	0.8942
Strongly correlated	0.7046	0.8565	0.8907

The balanced row spoils the clean story: the simpler z-score baseline wins. The fitted model's worst balanced seed is 0.6147. Its lead in the two displayed correlated regimes is an advantage under particular assignment conditions, which is more useful than declaring normalization solved.

Production ranking uses the fitted model. The normalization sandbox exposes alternative calculations for comparison, including raw means and within-reviewer z-scores, but is read-only; it does not select a different publication method. That makes the losing balanced result relevant to the system I actually built. The comparison is there to inspect the choice, not to make its cost disappear. Production ranking, sandbox.

The bundled fixtures answer a different question. They contain 41 projects, 30 registered judges and 126 imported ballots. Dry Relay moves from raw rank four to adjusted rank one; Slow Trail moves from six to nineteen. There is no known true ranking in those fixtures. Movement shows that the model changes decisions, not that it improves them. The import's equal criterion weights are an implementation choice, not an asserted organizer rule. Fixture report.

Giving the fit more computation produced another awkward result. Three outer rounds with a 200-iteration inner cap did not converge on the fixture data. Twelve rounds with a 1,000-iteration cap settled the fit. In the separate holdout check, which keeps some ballots out of fitting and predicts them, weighted-score RMSE increased from 1.017 to 1.038. The optimizer was more settled. Its predictions were slightly worse.

The larger iteration budget is the production default. It does not guarantee convergence on another event, so the warning still matters. Settling the fit and testing its predictions remain separate jobs.

Keep a second kind of judgment in its own model

Rubric judging asks how a project performed on weighted criteria. Pairwise judging asks which of two projects a reviewer prefers. Those observations can both be useful without sharing a numerical scale.

Manak uses a separate Bradley–Terry model for pairwise evidence. Its fitted strengths describe relative preference. They are not rubric-score units, so adding them to a normalized rubric result would manufacture a conversion the observations do not supply. A skipped comparison is excluded from the pairwise input rather than quietly counted as evidence for either project.

Connectivity matters here too. A set of preferences inside one group does not establish its position relative to an unconnected group. Missing, disconnected or nonconverged pairwise evidence must not produce confident finalist probabilities. The implementation keeps those checks between the fit and the recommendation.

The same restraint applies to uncertainty in rubric results. Overlapping approximate 95% bands can call for more evidence; they do not establish that the projects are equivalent. A request for another review is a useful output when the current evidence cannot support the precision of the proposed decision. Another decimal place is cheaper to generate, but it answers a different question.

Give publication an explicit boundary

A live dashboard should reflect new evidence. A ceremony needs a stable account of the decision that was actually made.

Manak stores a publication revision with the rubric version, algorithm and options, evidence digest, ledger head and report. The publication command builds the report and stores the revision in a transaction. The outer transaction uses SQLite's BEGIN IMMEDIATE; nested operations use savepoints. Evidence is hashed in stable primary-key order while the write lock is held, and the mutation and ledger append commit together. The report, digest and revision therefore share a transaction instead of being separately committed descriptions of a moving event. Public results and explanations read the stored report.

The regression test is deliberately rude to this boundary: publish revision one, then change a ballot. The published project results must stay fixed. An explicit second publication creates revision two, and award decisions attached to revision one stop applying. Carrying them forward would attach a decision to evidence the organizer had never approved. Publication code, regression tests.

The audit ledger uses a linear SHA-256 hash chain. That makes continuity inspectable. Someone with database write access can still recompute the whole chain, so detecting that rewrite requires a head anchor retained independently. The anchor is part of the design's trust condition; the local chain alone cannot make the database tamper-proof.

Awards are explicit organizer decisions attached to a publication revision. Only those decisions can mint placement certificates. A sorted list supplies evidence. The organizer still owns the award.

Build an ending that survives the server

A certificate record becomes a canonical ordered field array, then a SHA-256 digest and an Ed25519 signature. The signed fields bind the issuer key, publication revision and evidence digest. Version three also binds the template presentation and logo hash. A certificate can look convincing while its record is wrong, so the signed content needs its own verification path.

An offline browser or a standard-library Python verifier can check the signature. Both need an independent reason to trust the issuer public key. Neither can discover a later revocation, establish an external identity or prove the award was deserved. Those limits determine what the verification result means. Certificate implementation, Python verifier.

The tests check an original certificate, change its recipient name and require verification to fail. A different public key must fail too. A separate test issues legacy, v2 and v3 records, including Unicode, and invokes the Python CLI against them. The valid records pass; altering the v3 recipient name makes the CLI exit one. That tests the handoff between the issuer and a second implementation of the verifier. Signature tests, Python verifier tests.

Data needs an exit too. The archive roundtrip proof exports 162 rows across 33 table files, imports them, exports again and finds zero differing files. It also feeds the importer eleven damaged archives. All are refused, with zero rows committed by those refusals. A failed import that leaves half an event behind would be a rather expensive interpretation of “failed.”

The difficult part is making the stages agree

Several of these choices trade convenience for a decision that retains its meaning:

Decision	What it preserves	What it costs
Keep conflicts and capacities hard	Eligible judging evidence	Coverage may remain incomplete
Wait for community voting to close before publishing	A completed evidence window	Publication must wait
Bind awards to publication revisions	The result the organizer approved	Decide again after republishing
Require an explicit placement decision	Organizer ownership of the award	Record the placement before minting
Withhold unsupported pairwise probabilities	An honest account of the evidence	Sometimes collect another review

Testing those choices meant pushing on the connections: enumerate assignments, change a ballot after publication, damage an archive, inspect the ledger after a refused write. The full 15-stage API lifecycle then joins the pieces, including refusing publication while voting is open and allowing it after voting closes.

On 1 October 2026, the local checks ran again with Node 24.18 on Windows, including the official checker against a clean seeded local demo. Keeping the scope beside the count makes the results easier to use:

Check	Recorded result	Scope
Official acceptance after repairs	7 probes pass; T1/T2 verified	T3/T4 remain unverified by this checker
Project-authored extended checker	18 verified, 0 failed, 7 partial, 3 blocked	Additional probes, not official tier acceptance
Test suite	608 tests: 607 pass, 0 fail, 1 skip	Local run; skipped Windows SIGTERM-related case
Integrated API workflow	15 stages pass	Local lifecycle, including the voting/publication boundary
Command isolation	1,224 requests; 674 refusals; 418 refused writes; 0 refused-request ledger appends	Declared command matrix through sockets
Assignment enumeration	512 eligibility graphs, two target values	Three projects, three judges, fixed capacities
Normalization sweep	1,180 synthetic events	Rank recovery against planted truth under constructed assumptions
Archive roundtrip	162 rows; 33 table files; 0 export differences	Exported payloads; 11 damaged archives refused
TypeScript check	Passes without diagnostics	Development compiler, separate from runtime dependencies

The extended checker is mine. Its ledger probe checks links and the head, rather than independently rehashing every payload. Its webhook probe covers payload generation, rather than establishing receiver delivery and retry behavior. Those are reasons to keep the deeper tests and proof reports, not to relabel a partial probe as a complete workflow. Some blocked probes concern voting and shuffle on the fixture whose voting window is closed—the completed state preserved by the opening repair.

The proof reports are reproducible too. This command checks the isolation report against its committed result:

$ npm run prove:isolation -- --check
prove:isolation OK — 1224 requests, 6 witnesses, 674 refusals, none of which appended to the ledger; docs/proof/isolation.md reproduced byte for byte.

A report that can disagree with the code is more useful than another green badge.

In my previous write-up, I looked at the responsibilities that remain after removing dependencies. Manak made that responsibility concrete at a different level: every stage can follow its local rules while the event as a whole is wrong.

The opening report had already demonstrated it. The server accepted a timestamp inside the stored window. The checker completed. The failed probe revealed that the window no longer represented the closed event. The repair was only a separate SQL binding, but understanding why it mattered required keeping all three facts together.

The score is the compact output of this work. What I want to outlive the leaderboard is the explanation: what the judges saw, what the model did with it and exactly which result the organizer approved. Building the portal meant making those answers survive each transition, including the ones introduced by my own setup code.

Source code · Demo · Demo video

Sai Ram Dash (Hardik), Nastik AI. Built for the Hackathon Raptors;

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).