A Fork button on every tool (and why I hardened a hyperlink)
I added a Fork button to all 41 utilities — each one deep-links to its own source file. Then, because I can't leave well enough alone, I spent a second pass hardening a hyperlink until it had unit tests. A short essay on small features done exactly right.
There is a particular moment, maybe a minute into using a small tool, where you stop thinking about your task and start thinking about the tool itself. You paste a hex code into the color converter, watch it spit back HSL, and some quiet part of your brain asks: how does this actually work? Could I just have this one?
For the forty-one tools on /utilities, the honest answer has always been yes. They're open source, every one of them runs entirely in your browser, and the whole repository has been public the entire time. But "the code is public" and "here is the code for the thing you are looking at right now" are very different promises, and until last week the page only kept the first one. This is a note about closing that gap with a single button — and then, because I apparently cannot leave well enough alone, spending a second pass hardening that button until a hyperlink had unit tests.
The smallest honest version
The feature is almost too small to describe. Every tool page now has a Fork button in its top-right chrome, sitting next to the favorite star and the copy-link icon. Click it and you land on that exact tool's source file on GitHub — not the repository root, not a search results page, the file. The color picker's button opens ColorPalette.jsx. The regex tester's opens RegexTester.jsx. Eighty-odd lines, the thing you were just using, ready to read or copy or fork.
I did think about pointing all of them at the repo homepage instead. It would have been one constant string and exactly zero bookkeeping. But a link to the repo root says the code is somewhere in here, good luck; a link to the file says here is this thing. You arrived because you wanted one tool. The button should respect that you came for one tool.
One edit, forty-one tools
Here is the part that made it worth doing at all. Every tool on the page renders inside a single shared shell component called UtilityLayout. The back link, the title, the tag pills, the little Bauhaus accent bar, the theme toggle — that's all the shell, and each tool just hands it some children to draw in the middle. Which means a button added to the shell shows up on every tool at once. One edit, forty-one doors.
The only genuinely new information the button needs is which file each tool lives in. That's a small map from a tool's id to its path in the repo, plus a four-line helper that turns an id into a GitHub URL:
export function toolSourceUrl(id) {
if (!id || !Object.prototype.hasOwnProperty.call(TOOL_SOURCE_FILES, id)) {
return null;
}
return `${REPO_BLOB_BASE}/${TOOL_SOURCE_FILES[id]}`;
}A test that fails when I lie
A map like that has an obvious failure mode: it drifts. I rename a tool, or add a new one, or fat-finger a filename, and now a Fork button points at a file that doesn't exist. A 404 behind a "view source" link is worse than no link at all — it's a small, confident lie. So the map doesn't get to be trusted. It gets tested.
The test reads the route's own list of tools — the same map the app uses to decide what to render — and asserts three things: every routable tool has a source entry, no entry is left over, and every path it points at actually exists on disk. Add a tool without wiring up its source and the build goes red before anyone gets a chance to click. The site is structurally unable to ship a Fork button that 404s.
Then I did it again, to a hyperlink
I could have stopped there. It worked, it shipped, the checks were green. Instead I opened a second pull request titled, with a completely straight face, Harden the "fork me" sticker. It is a hyperlink. What, exactly, is there to harden?
Two things, it turned out. One a real bug, one a matter of feel.
The bug hiding in a lookup
The helper's contract is simple: hand it a tool id it knows, get a URL back; hand it anything else, get null. The first version implemented that by reading the id straight out of the map and checking whether the result was truthy. For all forty-one real tools, flawless. But JavaScript objects inherit keys from their prototype, which means a handful of strings are never missing from any object:
toolSourceUrl('color') // → …/tools/ColorPalette.jsx
toolSourceUrl('not-a-tool') // → null ✓ expected
toolSourceUrl('constructor') // → …/blob/main/function Object() { [native code] }
// ↑ a real-looking link to a file that cannot existNobody is ever going to visit /utilities/constructor. The bug is unreachable in practice and I know it. But the function claimed a contract — unknown id returns null — and quietly broke it for a small set of inherited names like constructor, __proto__, and toString, handing back a confident URL to a file that will never exist. The fix is one line: check that the map actually owns the key before trusting it, then freeze the map so nothing downstream can mutate it. And then a test pins all of it shut — empty string, undefined, constructor, __proto__ — because the entire point of finding a bug like this is making sure it can't quietly come back.
A button should feel like a button
The second change was smaller and entirely about feel. The first Fork pill just sat there — correct, inert, a little dead. Every other control in that row responds when you reach for it; this one should too. So now, on hover or keyboard focus, the pill's border lifts into the tool's own accent color — the same hue as the bar under the title, picked per-tool. It is a two-property change wired to four event handlers, and it is the whole difference between a link and a control.
The size of a change and the care it deserves are unrelated quantities.
Why bother, for a link
Open source that doesn't tell you where the source is is a house with the key left under the mat: technically unlocked, practically closed. The Fork button is just the sign on the door — yes, this one, take it. It costs a corner of the viewport and it earns the page the right to call its tools open without a quiet asterisk.
And the hardening pass is the same instinct that produced the tools in the first place. The rule for every utility here is: do one thing, do it exactly right, ask for nothing. A "view source" link that points at the wrong file, or 404s, or one day hands back a URL to function Object() { [native code] }, would be that one thing done almost right — which, for a tool, is indistinguishable from done wrong. The tests are there so the page never has to tell even a small lie.
It is forty-one buttons and a hardened hyperlink. It took an afternoon. I would do it again, and given the second pull request, I evidently already did.