A Fork button on every tool (and why I hardened a hyperlink)

Small feature. Maybe too small to bother writing up. But every tool page now carries a Fork button in its top-right chrome, parked beside the favorite star and the copy-link icon, and clicking it drops you onto that exact tool's source file on GitHub. Not the repository root, not a search results page. The file. Color picker opens ColorPalette.jsx. Regex tester opens RegexTester.jsx. Eighty-odd lines, the thing you were just using, sitting there to read or copy or fork.

The lazy version was tempting. Point all of them at the repo homepage: one constant string, no bookkeeping to maintain. I didn't, and here's why. A repo-root link tells you the code is somewhere in here, good luck. A file link tells you here is this thing. You arrived wanting one tool. The button owes you that much.

The shell is what made this worth doing. UtilityLayout wraps every tool on the page, and it draws almost everything you see: back link, title, tag pills, the little Bauhaus accent bar, the theme toggle. Each tool only supplies children for the middle. Add a button to the shell and it lands on all of them. One edit, forty-one doors.

What does the button actually need to know? Only which file each tool lives in. So: a small map from a tool's id to its path in the repo, and a four-line helper that turns an id into a GitHub URL.

A map like that has an obvious failure mode: it drifts. I rename a tool, add a new one, fat-finger a filename, and suddenly 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 it checks three things: every routable tool has a source entry, nothing 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 to click. The site is structurally unable to ship a Fork button that 404s.

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's a hyperlink. What is there to harden?

Turns out, two things. One a real bug. One just a matter of feel.

The helper's contract is simple. Hand it a tool id it knows, you get a URL back. Hand it anything else, you get null. Version one did that by reading the id straight out of the map and checking whether the result was truthy. Flawless across all forty-one real tools. The problem is that JavaScript objects inherit keys from their prototype, so a handful of strings are never missing from any object:

Nobody is ever going to visit /utilities/constructor. I know that. The bug is unreachable in practice. But the function claimed a contract - unknown id returns null - and then quietly broke it for a handful of inherited names like constructor, __proto__, and toString, handing back a confident URL to a file that will never exist. One line fixes it: check that the map actually owns the key before you trust it, then freeze the map so nothing downstream can mutate it. Then a test nails all of it shut. Empty string, undefined, constructor, __proto__. The whole point of finding a bug like this is making sure it can't sneak back.

The second change was smaller, and it was all 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, so this one should too. 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. Two properties wired to four event handlers. That's the whole difference between a link and a control.

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.