One game, many sites, no drift

Chalk Up! was born on Västervik Bouldering: five granite boulders a day, a chalk bag, a beer at the top. It lived inside that site's theme, borrowing its colours, its fonts and its buttons. Then I wanted it on Rebel Kayaks and The Outdoor Hub too. Problem. This is about sharing one piece of code between several websites, and the quiet way that goes wrong: copies that stop following the original. Run more than one site from one codebase, and you have this problem whether you've noticed it or not. Why there are copies at all Each site is its own app, deployed on its own. A shared package works for components, but not for pages: the framework only finds a page inside the app itself. So every site carries a copy of the game. One source in the shared core, and a sync tool writes identical copies. The copy that stops listening It has bitten before. For a long time the sync tool skipped any file that already existed in a site, so a copy froze at its first sync and never heard about a fix again. Since a few days ago it remembers a fingerprint of what it last wrote. A copy nobody touched gets updated. A copy somebody edited is treated as a deliberate local change, and left alone. That second rule is correct, and it is also the trap. Fix a bug in one site's copy, and you haven't fixed the game. You've forked it, silently, and the next fix to the source will never reach that site. Nothing warns you. The site just slowly gets worse than its siblings. A look that travels with the game My call: Chalk Up! keeps its own look everywhere, Steffo and all, and only the page around it belongs to each site. So the game got its own palette (same colours, its own names), its own buttons and its own fonts, under family names no site would ever use. A punk kayak site and a calm outdoor site can't bleed into it. Moving it was supposed to change nothing on its home site, so we checked by machine: screenshots before and after, compared pixel by pixel. 46 pixels out of 941,600 differed, all animations caught mid-frame. What sync doesn't do Sync handles code. Some parts of a game aren't code: The sounds and fonts sit in each site's public folder, and nothing syncs those. Change a sound and you copy it by hand to every site that has the game. Each site's switch for the game, and the card on its games page. The portfolio. idunworks.com now has a games page that shows every game and links to where it's played. Add or move a game and that card needs updating too. And sometimes the change goes the other way. RUGD dropped its games entirely that same evening, so I deleted its copies and the sync was told never to bring them back. Otherwise the next sync would have quietly restored them. From notes to a tripwire When it was done, the question was simple. So is the game one codebase, more or less? More or less, yes. One source, three identical copies, and a short list of things done by hand. We wrote the list down as a note the AI reads when it seems relevant. But does the note get read every time a game changes? Honestly, no: a note is read when a session decides it matters, and the mistakes happen when nobody thinks it matters. So we added a hook: a small script that runs every time a file is edited, and stays silent unless the file belongs to a game. Then it says one of three things, depending on what was touched: case $kind in source) msg="Shared game source edited: sync it to every site afterwards." ;; copy) msg="This is a site's COPY. Edit the source instead: an edited copy stops getting updates." ;; static) msg="Sounds and fonts aren't synced. Copy this file to every site with the game." ;; esac The first time in a session it also hands over the whole checklist; after that, one line. It talks on two channels: the full text goes to the AI, so the next step already knows, and a short line with a 🎮 shows up for me. A site's own games page stays silent, because that file really does belong to the site. We tested it on a real one-line edit to a game file. There was the checklist. What happened, and how else it could be done Edited copies stop updating: one source, synced copies, and a warning the moment someone edits a copy. Assets aren't synced: the hook says so. A shared game could take on its host's look: it carries its own palette and fonts now. Other ways to do it: One app serving every site. No copies at all, but one deploy for everything, and one bad release takes down every site at once. We deploy one site at a time on purpose. Also, it is fun to design variants in look and feel. Because I can. This would probably not scale to high-traffic but it's easy to redo should the need arise. A check that blocks the build when a copy differs from its source. Stricter than a reminder, and probably where this ends up. The reminder comes first because it costs nothing and catches the mistake while it's being made, not in a failed deploy an hour later. Syncing the static files too. That would close the last hand-copied gap, at the price of one more thing that can overwrite a site's own picture. If you share code between sites: Keep exactly one place where a change is allowed to start. Make the copies know whether they've been touched. Write down what isn't synced, and then don't trust the note: put the reminder where the edit happens. Prove a move changed nothing, by machine. Five boulders a day, now on three sites: chalk up. Originally published at idunworks.com.