DEV Community: 99 tools

The hardest part of automating Mafia was the player who was already dead 🪦

99 tools — Fri, 18 Sep 2026 08:42:54 +0000

A game of Mafia usually starts by picking someone who doesn't get to play. They run the night, watch everyone point in the dark, and announce who didn't survive. At a table of five that's a fifth of the room, and it's usually whoever knew the rules well enough to explain them.

So I built a mode where the phone runs the night instead and everyone plays.

Then I solved a problem I was very pleased with, and spent rather less time noticing I'd given the answer away somewhere else entirely.

The problem

Night two. The obvious thing is to check who's still alive and skip the roles whose players are gone. Why wake a Detective who died last night?

Because skipping their turn tells the room the Detective is dead.

Everyone is sitting there with their eyes shut. They can't see anything, but they can hear the shape of the night. Last night there was a pause where the Detective did their thing. Tonight there isn't. That silence is free information, handed to every player — including the Mafia, who now know which power role is off the board.

Human moderators have long known this. You call the dead role anyway. You pause as though someone is deciding. Then you tell them to close their eyes.

So the machine does too:

const detective = name('detective', naming);
const alive = livingWith(game, 'detective').length > 0;

steps.push({
  id: 'detective-pick',
  line: `${detective}, tap the number of the person you are looking at tonight.`,
  ...(alive
    ? { pick: { of: 'check', from: seats }, hold: 0 }  // stop, wait for a tap
    : { hold: THINKING }),                             // 6.5s, then move on
});

Same words either way. With your eyes shut, a night where the Detective is dead sounds exactly like one where they aren't. I was pleased with this.

The part I missed

Then I opened my own tool.

"Ada did not survive the night. **They were a Doctor."

Reveal-on-death. It's the default I shipped, and it announces in broad daylight the exact fact the night code works so hard to hide. Every careful pause I'd built was guarding a secret the app had already read out to the room.

The precaution isn't wrong. It's conditional. It only does anything when you turn "say what they were" off — the harder game, and not the one the tool hands you by default.

What I actually learned

Not "silence is information", though it is.

The thing worth taking away is that an information leak is a property of the whole system, not of the function you happen to be looking at. My night code was careful. My morning code gave the same fact away for free — 115 lines further down the same file, in the same commit, written the same afternoon. Both were correct on their own, and I still didn't see it. You can't review a leak function by function. You have to ask what a player knows by the end of the round, and work backwards.

I've kept the precaution in, because it's never wrong. But I'd assumed it was nearly free, and when I actually added up the steps around it — wake the role, ask the question, hold the silence, send them back to sleep — a dead Detective costs 22 seconds a night, and a dead Doctor 18. With both gone that's 40 seconds of dead air, every single night, spent convincing a room that two people who aren't there are still thinking.

Which makes the default it's guarding look much worse.

So, a question

Should role reveal be on by default?

On, and the game is easy to follow — you know what's left, the day's argument has real information in it, and a first-timer can keep up. Off, and every timing precaution suddenly earns its keep, deduction gets genuinely hard, and the game is better for a table that's played before.

Right now it's on, because it's friendlier — which means anyone on the defaults is paying up to 40 seconds a night to hide something the app announced at breakfast. I'm not sure that's the correct call. If your table has a strong opinion, I'd like to hear it.

And a broader one: what else should be digitised? This started as a role dealer and became a narrator because it turned out the machine could do the boring half of the job. Other games have that shape — Coup, Avalon, Wink Murder, anything where one person ends up as the admin instead of a player. If that's a game your group plays, tell me and I'll have a go.

👉 99tools.dev/tools/role-dealer — set the narrator to Godless, deal, pass the phone round, and it runs the night. Free, no sign-up, entirely in your browser.

Two bugs that shipped 114 tools' JavaScript to every page

99 tools — Fri, 11 Sep 2026 14:36:02 +0000

I've been building a set of browser-based developer utilities — JSON formatting, diffing, hashing, image and PDF work, that sort of thing. 114 of them now, all on one Next.js static export.

Two problems took far longer to understand than to fix. Both are the kind that don't announce themselves.

1. Every page shipped every tool's code

The site has a registry: one module listing every tool, its metadata, and its React component. The header imports it to build the search palette. That seemed harmless.

It wasn't. Here's the rule I didn't know:

In the App Router, a server module that references a 'use client' module — statically, through next/dynamic, or through a lazy import() thunk — has that module's chunk attached to every route that imports it.

next/dynamic felt like it should defer the cost. It doesn't. It defers execution, not chunk attachment. And because the registry was imported by the layout's header, it was imported by every page — so every page carried every tool's JavaScript, including the PDF library, the OCR engine, and the image processing code.

A visitor opening a JSON formatter was downloading a barcode scanner.

The fix was a split by concern:

the registry holds data only — slugs, names, categories, keywords
the UI map lives in its own client module
the prose map is server-only

Nothing clever, but you have to know the rule first. If you want to check your own: ANALYZE=1 next build emits source maps you can inspect.

The tell, before I understood the cause, was that every page had suspiciously similar JS weight regardless of what was on it. If your pages all cost the same, something shared is pulling everything in.

2. A 26.5 MB file I never load broke the entire deploy

The deploy started failing with Asset too large. The site is static files on Cloudflare, which has a 25 MiB hard limit per asset — and exceeding it fails the whole deploy, not just the page that needs the file. Nothing else ships.

The culprit was a WebAssembly build I never use.

I use ONNX Runtime Web for one tool, pinned to the plain WASM backend. But the package also ships a JSEP build — the WebGPU/WebNN variant — and it contains its own new URL(..., import.meta.url) reference. The bundler traced that reference and emitted a copy of the 26.5 MB file into the output.

Nothing in my source mentions it. No page requests it. The runtime is explicitly pinned:

ort.env.wasm.wasmPaths = '/wasm/ort/'
ort.env.wasm.executionProviders = ['wasm']

It was emitted purely because a file inside a dependency referenced itself in a way the bundler follows.

The fix was an ignore file listing that one asset so it isn't uploaded — kept deliberately narrow, because the other ONNX wasm file in the same folder is the one the tool actually needs. A broad pattern there silently breaks the feature.

Cloudflare also caps at 20,000 files. Worth knowing before you generate a page per item.

What I'd tell someone starting this

Bundlers follow references inside your dependencies, not just yours. A file you never import can end up in your output because something in node_modules pointed at itself.

Static-host limits fail loudly but late. Per-asset size and file count are worth checking on day one, not on deploy day.

"Lazy" in a bundler usually means deferred execution, not deferred download. Verify which one you're getting.

Make the build check itself. Mine now runs 3,877 assertions over the output directory before deploying, and refuses to ship if any fail. The tool logic has 3,175 tests of its own. Most of both exist because of a specific thing that broke once.

The tools are at 99tools.dev if they're useful to you. Everything runs in the browser — nothing you paste is uploaded, and they keep working with the network disconnected. Two exceptions, badged in the UI: the DNS lookup and the IP viewer genuinely need a server. Analytics is the cookieless kind, and there's nothing to sign up for.

Happy to answer questions about either bug.