DEV Community: Prince Panchani

Migrating a 5-year-old React admin app from CRA + Webpack to Vite + SWC — 166 files, 70 days

Prince Panchani — Sun, 23 Aug 2026 11:12:08 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The build was fine. Everything else was on fire.

Every codebase has a number that nobody says out loud.

Ours was the time between hitting Ctrl+S and seeing the change in the browser. Long enough to check Slack. Long enough to forget what you were testing. On a cold start, long enough to make coffee.

DreamNet is the internal admin platform for ZURU's housing division — user management, RBAC, asset catalogues, project publishing, release builds, an order-pricing engine, event management, dashboards with charts and maps. Roughly 130 source files across src/scene alone. It was scaffolded with Create React App and had been running on react-scripts@3.0.1 — a release from 2019 — held together with rewire, env-cmd, and node-sass@4.14.1, which needed a specific Node version to even compile.

The proposal was simple: replace the build tool. Vite + SWC. Faster cold start, near-instant HMR, better production builds.

The reality was that the build tool was the only part that went smoothly.

This is the story of MR — 166 changed files, 28+ diff revisions, 19 review comments, and 70 days between "let's swap the bundler" and green on production.

Why a bundler swap is never a bundler swap

Here's the thing nobody tells you about CRA: CRA is not a bundler. ** CRA is an API.

Over five years, a codebase doesn't just use webpack. It absorbs webpack's semantics into its source. process.env, %PUBLIC_URL%, import { ReactComponent as Icon }, JSX inside .js files, implicit Node globals in browser code, automatic Babel transpilation of every CommonJS dependency you ever installed.

None of those is React features. All of them are load-bearing.

So the first thing I did was not write vite.config.mjs. I ran a survey: every place the source assumed that only webpack could satisfy. That list became the actual scope of work — and it was about ten times larger than the config file.

The config file, for the record, is 23 lines:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react-swc';
import svgr from 'vite-plugin-svgr';

export default defineConfig({
  plugins: [react(), svgr({ exportAsDefault: true })],
  envDir: 'environments',
  server: { port: 3000 },
  preview: { port: 3000 },
  build: { outDir: 'build' },
});

build.outDir: 'build' and port: 3000 are deliberate. Vite defaults to dist and 5173. Our GitLab CI jobs, Docker image, and deploy scripts all expected build/ on :3000. Changing the bundler and the deployment contract in the same MR is how you end up with a broken pipeline you can't attribute to anything. Absorb the churn in config, not in infrastructure.

Constraint one: React 16 stays

The tempting move here is to bundle the migration with a React 18 upgrade. ReactDOM.render is deprecated, createRoot is right there, and you're already in the file.

I didn't. We stayed on react@16.14.0, ReactDOM.render, and react-router-dom@4.3.1. All of it.

The reasoning: a build migration has no user-visible intent. If nothing changes for the user, then every visual or behavioural difference is a regression, full stop. That is an incredibly powerful invariant to review against — the reviewer can just diff the two environments side by side, and any delta is a bug. Fold a React 18 upgrade in, and you lose it: now some differences are expected, some aren't, and every discussion becomes an argument about which is which.

The MR is labelled a breaking change for tooling. It should be a no-op for behaviour.

Chapter 1: `type: module` and the file-extension domino

Adding "type": "module" to package.json is one line. It cost a day.

Node now treats every .js file in the project as ESM. Which means:

.eslintrc.js used module.exports → crashes. Renamed to .eslintrc.cjs.
The Vite config had to be .mjs to be unambiguous.
.lintstagedrc.js had to be written as export default { ... }.

Then esbuild's rule hit: esbuild will not parse JSX inside a .js file. Babel happily did. esbuild refuses, by design, because the .js extension makes no promise about JSX and guessing costs parse time.

That forced a wave of renames — src/app.js → app.jsx, src/index.js → index.jsx, src/service/apollo_wrapper.js → .jsx — and one genuine refactor. src/constants.js was a data module that had quietly grown JSX in it: nav configs, ingredient lists, session-OS maps, all carrying icon: <AacIngredientIcon />. I split it into a new src/constant.jsx holding everything JSX-bearing, leaving constants.js as pure data.

That split turned out to be worth doing on its own merits — it stopped a 200-line render-bearing module from being imported by things that only wanted string constants.

Takeaway: extension discipline feels like bureaucracy under Babel. Under esbuild it's a type system. It's a better default.

Chapter 2: `process.env` doesn't exist in the browser

CRA injected process.env into browser code. Vite doesn't — it exposes import.meta.env, and only for variables prefixed VITE_.

Every REACT_APP_* reference had to move. src/config.js alone was a solid block of it:

- const cloudFunctionsEnvironment = process.env.REACT_APP_API_ENV;
- export const serverProxyURL   = process.env.REACT_APP_PROXY_URL;
- export const redirectURL      = process.env.REACT_APP_REDIRECT_URL;
+ const cloudFunctionsEnvironment = import.meta.env.VITE_API_ENV;
+ export const serverProxyURL   = import.meta.env.VITE_PROXY_URL;
+ export const redirectURL      = import.meta.env.VITE_REDIRECT_URL;

…plus the entire cookie-name map, which derives ten keys off VITE_COOKIE_PREFIX, and the OAuth token-refresh config in helper.jsx.

The subtle part isn't the rename. It's that process.env.FOO on an unset variable silently yields undefined, and you get a broken URL at runtime. There is no build-time error. A single missed rename ships a undefinedaccess_token cookie to production, and you find out from a support ticket.

Two things de-risked this:

A grep-and-verify pass, not a find-and-replace pass. Every hit reviewed individually, because some process.env references were in Node-side config that should stay process.env.
Consolidating the env files. CRA's env-cmd setup had .env, .env.local, .env.localV2, .env.development, .env.staging scattered at the repo root, selected by npm script. I moved them into environments/ and let Vite's native mode flag drive selection:

"local":       "vite --mode localhost",
"build:dev":   "vite build --mode development",
"build:stage": "vite build --mode staging",
"build":       "vite build"

with envDir: 'environments' in the config. env-cmd deleted. One mechanism instead of two, and the mode name is now visible in the command you actually type.

index.html also moved from public/ to the project root — Vite treats it as the build entry, not a template — and %PUBLIC_URL% placeholders became plain absolute paths.

Chapter 3: the white screen with no stack trace

First successful build. Open the app. White screen.

Console: Uncaught ReferenceError: global is not defined.

This is the migration bug that eats an afternoon, because the error points at bundled vendor code and tells you nothing about why it's there.

The cause: global is a Node identifier. It does not exist in browsers. Webpack, being a Node-first bundler, silently shimmed it for every CommonJS dependency that reached for it. Vite — an ESM-first, browser-first bundler — does not.

Our dependency tree was old enough to be full of candidates. socket.io-client@2.3.0 and draft-js@0.10.5 are both from an era when "just assume global" was normal library code. Because the reference is inside a dependency, you can't fix it in your own source.

The fix I shipped is deliberately blunt — a shim in index.html, before the module entry:

<script type="module" src="./src/index.jsx"></script>
<script>
  var global = global || window
</script>

Why this and not define: { global: 'window' } in the Vite config?

define does a raw textual substitution across every module at build time. That's a shotgun: it rewrites the identifier global everywhere, including inside strings and comments in dependency code, and it behaves differently in dev vs build. I hit a real inconsistency between vite dev and vite build output while testing it.

The HTML shim is honest about what it is: one global, defined once, in the document, visible to anyone who opens index.html. It's not elegant. It's legible, and for a shim whose entire purpose is to be deleted the day those two dependencies get upgraded, legibility beats elegance.

That's the trade-off I'd defend in review, and did.

Chapter 4: five dependencies that couldn't make the jump

This is where the migration stopped being about the build and started being about the product.

Some packages simply don't survive contact with ESM + esbuild — they ship CommonJS-only, depend on Node builtins, or were abandoned before ESM mattered. Five had to go:

Package	Replaced with
`reactjs-localstorage`	a 15-line `storageWrapper`
`rc-time-picker-date-fns`	native `<input type="time">`
`react-sortable-hoc` + `array-move`	plain function-returned JSX
`react-numeric-input`	native numeric input
`node-sass@4.14.1`	`sass@1.69.7` (Dart Sass)

node-sass deserves a footnote: it's a native binding compiled against a specific Node ABI. It's the reason the project was pinned to an old Node in the first place. Deleting it is what let CI move from node:14.16.1 to node:16.20.2 — which Vite 4 requires anyway. One dependency was holding the entire toolchain hostage.

reactjs-localstorage was the easy one. The library's whole surface is get/set/getObject/setObject, and helper.jsx had grown nine thin wrappers around it (StoreCookie, GetDcIdToken, StoreLastLoggedInUser, DeleteIdTokenCookie…) most of which nothing called any more. I replaced the package and the nine wrappers with one object:

export const storageWrapper = {
  set: (key, value) => {
    localStorage.setItem(key, typeof value === 'string'
      ? value
      : JSON.stringify(value));
  },
  get: (key, defaultValue) => localStorage.getItem(key) || defaultValue,
  remove: (key) => localStorage.removeItem(key),
  clear: () => localStorage.clear(),
};

Net: one dependency and ~40 lines of dead abstraction deleted, and the call sites got clearer — GetStorePermission() now visibly does JSON.parse(storageWrapper.get('DC_PERMISSION', [])) instead of hiding the parse inside a library method named getObject.

react-sortable-hoc was the interesting one. The reviewer's call was not to find a replacement drag-and-drop library at all — the sortable behaviour on the jobs dashboard wasn't actually used — and instead unwrap SortableContainer / SortableItem back into plain functions returning JSX, preserving the code structure so the diff stayed reviewable. Removing a feature is a legitimate answer to "this dependency won't build." It's just the one nobody suggests.

Chapter 5: `ReactComponent` was never a real thing

CRA let you do this:

import { ReactComponent as ClockIcon } from './clock.svg';

That named export is a webpack loader convention. It is not part of any standard. Vite has no idea what you mean.

vite-plugin-svgr covers the common case, and I added it. But the reviewer caught a genuine inconsistency: I was using svgr in some files and <img src={...} /> in others, with no rule for which. That's the kind of thing that looks like a nit and is actually a maintenance tax — the next person has to read the imports to know what an SVG is in this codebase.

The rule we landed on, and the reason for it:

Static, decorative SVGs → <img src={Icon} />. Cheap, cacheable, no parse cost.
SVGs that need to respond to the theme → hand-authored inline JSX components in src/images/svg_helper.jsx.

That second category is the interesting one. DreamNet has a dark mode driven by CSS custom properties. An <img> is an opaque replaced element — it cannot inherit --aurora-colors-text from the page. So the dropzone's upload icons, which need to be visible in both themes, had to become real DOM:

export const MobileIcon = ({ className }) => (
  <svg className={className} viewBox="0 0 27 43" ...>
    <rect stroke="var(--aurora-colors-text)" ... />
    <path fill="var(--aurora-colors-text)" ... />
    <path fill="var(--aurora-colors-primary-300)" ... />
  </svg>
);

The two .svg files they replaced were deleted outright. A pile of the review churn in this MR — fix: download icon dark mode issue, fix: calendar icon colour in dark mode, fix: Edit-icon in collection page in dark mode, fix: dark mode empty table text issue — is this exact class of bug, found one screen at a time.

Chapter 6: Fast Refresh has opinions about your exports

Two commits in this MR read resolve: resolve warning of fast refresh component and fix: remove warning of fastRefresh, and I want to explain them because the fix looks like a no-op.

React Fast Refresh can only hot-reload a module if it can statically prove the module's exports are all components. An anonymous expression export defeats that:

// Fast Refresh can't track this
export default withToast(Dropzone);

// It can track this
const DropZoneComponent = withToast(Dropzone);
export default DropZoneComponent;

Identical at runtime. Completely different for HMR: the first form silently forces a full page reload on every edit, which quietly deletes most of the developer-experience benefit you migrated for.

We wired eslint-plugin-react-refresh into the config so this is enforced rather than remembered:

plugins: ['react-refresh'],
rules: {
  'react-refresh/only-export-components': ['warn', { allowConstantExport: true }],
}

allowConstantExport: true matters — Vite supports mixing constant exports with component exports, and without it the rule fires constantly on legitimate files.

The same file also turned off react/react-in-jsx-scope and react/jsx-uses-react, because SWC's automatic JSX runtime means import React from 'react' is no longer required. That's why dozens of files in this diff lose their React import — it's not cosmetic, it's the transform contract changing.

Chapter 7: the chart.js version that went backwards

One line in package.json got a direct challenge in review:

Reviewer: Any specific reason to go backwards? Is it a compatibility issue with Node?

chart.js went 3.9.1 → 3.8.0. Downgrading a dependency during a modernisation MR looks like giving up, and it deserved the question.

The answer: at medium and small viewports, the Doughnut chart's legend swatches stopped picking up the light/dark theme colour. I bisected across chart.js patch versions, confirmed 3.8.0 was clean, and 3.9.1 was not, and found the matching upstream report — chartjs/Chart.js#10372.

Before

After

Pinning back to 3.8.0 with a link to the upstream issue is the correct call here, and I'd make it again. The alternative was writing a custom legend renderer to work around a known upstream regression, in an MR that already had 166 changed files and a hard invariant of "nothing user-visible changes." Scope discipline is a technical decision, not a project-management one.

Chapter 8: the reviewer who wanted zero

The single most valuable thing that happened to this MR was this comment:

After I ran npm run eslint-fix, I still see 90 warnings!!!! I think I have asked you to resolve it. Here is the patch I did in one of the files to resolve two of these. You can apply the patch with git apply mypatch.patch […] I want 0 errors/warnings here.

Attached: an actual .patch file demonstrating the fix pattern.

Ninety warnings is a normal number for a five-year-old codebase, and the reflexive response is "those are pre-existing, out of scope." That would have been wrong, and here's the concrete reason why.

While clearing them, ESLint surfaced this in event_details.jsx:

LocationOptions.prototype = {   // ← prototype
  locations: PropTypes.arrayOf(...),
};

prototype, not propTypes. A typo. Which means that component had never validated its props — the runtime type checks had been silently disabled since the day the line was written. No error, no warning, no symptom. Just a safety net that was never actually attached.

It's now propTypes, with a matching defaultProps. That's a real bug, in production, found by a lint pass that a lazier version of me would have argued was out of scope.

The lint gate now runs on every commit rather than on trust — husky's package.json hooks block replaced with a .husky/pre-commit script driving lint-staged, so only touched files get checked and the hook stays fast:

// .lintstagedrc.js
export default {
  '*.{js,jsx,ts,tsx}': ['eslint --fix'],
};

How this was actually validated (the honest version)

DreamNet has no automated test suite. react-scripts test existed in package.json and ran nothing. I'm not going to dress that up.

So validation was three things, and I'd argue the first one is underrated:

1. The invariant did the work. Because we deliberately changed no behaviour, "correct" was defined as "byte-for-byte identical to dev, on every screen." That turns verification from a judgement call into a comparison. The reviewer could — and repeatedly did — post side-by-side screenshots of dev vs the branch and say "this spacing is different," and there was no argument to have. Six weeks of review comments are almost entirely of that form.

2. The migration was kept alive against a moving target. dev did not freeze for 70 days. The MR absorbed merges of 31, 23, 15, 18, 35, 57 and 17 commits from dev over its lifetime. That was a deliberate choice over rebasing at the end: every merge is a small, attributable conflict resolution. One giant rebase at the end is an unreviewable mess where a subtle behaviour change hides indefinitely.

3. The deploy chain proved itself. .gitlab-ci.yml moved to node:16.20.2 across the lint, dev, stage and prod jobs, and the build was then exercised through the real pipeline — dev, then stage, then production — rather than trusted from a local npm run build. Vite's dev server and its Rollup production build are different code paths; a dev-only smoke test proves less than it feels like it does. react-numeric-input in particular only failed at build time, not in dev — commit fix: remove react-numeric-input package and resolve breaking changes in build.

Merged 4 January 2024. Still the build system today, now serving dev, stage, production and a Hong Kong deployment.

What it bought

⚠️ TODO before publishing: fill these in from your own machine. Run time npm run build on the merge commit f275733 and on its parent d46df1c, and time a cold vite/react-scripts start for both. Don't publish estimates.

	CRA + Webpack	Vite + SWC
Cold dev server start	`__`	`__`
HMR / file change reflected	`__`	`__`
Production build (CI)	`__`	`__`
Node version required	14.16.1	16.20.2
Direct dependencies	34	26
Build-tool devDependencies	15	7

The dependency numbers are the ones I care about most, honestly. react-scripts@3.0.1 was a single line in package.json that pulled in Babel, webpack, PostCSS, ESLint, Jest and their entire transitive universe, all pinned to 2019, all unupgradeable independently. Replacing it with vite + @vitejs/plugin-react-swc + vite-plugin-svgr means every one of those concerns is now a package we can move on its own schedule.

Takeaways

1. Migrate the build tool, not the app. Every change that isn't strictly required by the new bundler is a change that makes "is this a regression?" unanswerable. Staying on React 16 wasn't conservatism — it was what made the MR reviewable at all.

2. The dependencies are the migration. The config was 23 lines and one afternoon. Five incompatible packages were ten weeks. Audit package.json against ESM compatibility before you estimate, not after.

3. Removing a library is a domain-modelling exercise in disguise. rc-time-picker-date-fns didn't just render a widget — it imposed a data model where time and date were fused into one Date. Replacing it forced us to name the operation we'd always been doing badly (compareTimes), which is how the "can't schedule a future event in the afternoon" bug finally surfaced.

4. global is not defined means a dependency is older than ESM. Shim it visibly in index.html rather than invisibly via define. Leave a shim you can find and delete later.

5. Take the lint warnings seriously, especially the pre-existing ones. prototype instead of propTypes had silently disabled runtime prop validation on a production component. Ninety warnings hid exactly one real bug. That ratio is worth it.

6. Merge from main constantly on a long-lived branch. Seven merges from dev over 70 days, each a small resolvable conflict. The alternative is one enormous rebase where a behavioural change can hide with nobody noticing.

7. No test suite isn't an excuse — it's a constraint you design around. Ours was replaced by a hard invariant ("nothing user-visible changes") plus a reviewer with screenshots. Not as good as tests. Considerably better than vibes.

Thanks also to the open-source projects that made the destination worth the trip: Vite, SWC, @vitejs/plugin-react-swc, vite-plugin-svgr, Dart Sass, and Chart.js — whose maintainers had already documented #10372 by the time I went looking, which saved me a day.

If you've done a CRA → Vite migration on a codebase older than three years, I'd genuinely like to hear which dependency was your rc-time-picker. Everyone has one.

The 2021 Sentry bug that made every Element Desktop crash unreadable

Prince Panchani — Sat, 22 Aug 2026 17:34:17 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

On 22 November 2021, @novocaine opened issue #32242 on Element Web. He diagnosed it correctly, named the exact Sentry integration that would fix it, and left one open question he couldn't answer.

It sat there for four years and nine months.

On 12 August 2026 I shipped the fix — and answered his question.

Project Overview

Element Web is the flagship Matrix client — secure, decentralised, end-to-end-encrypted collaboration. 13.4k stars, 2.7k forks, ~3,600 open issues, AGPL-3.0. It ships as a web app and, packaged with Electron, as Element Desktop.

The user base matters here. Element is deployed by governments, hospitals, universities and armed forces — organisations that choose Matrix precisely because they can't hand their communications to a US SaaS vendor. Many of those deployments are desktop-first. Which makes it a genuine problem that, for nearly five years, Element Desktop was the one platform whose crash reports the maintainers couldn't actually read.

I contributed two merged fixes. This post is mostly about the Sentry one.

Bug Fix or Performance Improvement

The main event: Element Desktop's crash reports were minified garbage

Element Desktop doesn't serve the app over https://. Electron serves it from a custom protocol, vector://vector/webapp. So every stack frame Sentry captured on desktop looked like this:

vector://vector/webapp/bundles/abc123/bundle.js

Sentry's source-map resolver has no idea what vector:// is. It can't match that path against the uploaded artifacts for the release. Two things followed, and the second is the expensive one:

1. Desktop crashes arrived unsymbolicated. Minified function names, no original file, no real line numbers. t.default.a is not a function at bundle.js:1:284915. Technically a crash report; practically a shrug.

2. Desktop and web crashes stopped grouping. Sentry groups issues partly by stack frame filenames. Web reported https://app.element.io/bundles/abc123/bundle.js; desktop reported vector://vector/webapp/bundles/abc123/bundle.js. Same crash, same release, same line of source — two separate issues in Sentry.

That second one quietly corrupts your prioritisation. An issue hitting 600 users looks like two issues hitting 400 and 200. One of them is legible and one isn't, so the legible one gets triaged and the illegible one gets ignored — and the illegible one is the platform your enterprise customers are running.

novocaine spotted all of this in 2021. From the original report:

Sentry errors emitted by Element Desktop aren't being source-mapped, which means they aren't being grouped with the same exceptions on Element Web, and are harder to debug.

He even linked Sentry's RewriteFrames docs and said that's what should be used. Then he added the part that I think is why nothing happened for five years:

The bundle hash is also in the pathname, and it doesn't match web on the same release (not sure why this is) … I'm interested in why 2 is happening at all, it may lead to issues later on

An unanswered question inside a bug report is a very effective blocker. The issue got labelled S-Minor and O-Uncommon and went to sleep.

The other one: the high-contrast theme had no contrast

Separately, #34213: in Element's Light High Contrast theme, hovering a Spotlight search result rendered light grey text on a light grey background. Measured contrast ratio 1.38:1; WCAG AA requires 4.5:1.

The high-contrast theme was the illegible one. For users who enable high contrast because they need it, "Explore Public Rooms" was a blank row. More on that further down.

Code

PR	Status	What
element-hq/element-web#34667	✅ Merged	Sentry `rewriteFramesIntegration` for Element Desktop — closes a 2021 issue
element-hq/element-web#34465	✅ Merged	High-contrast Spotlight legibility + cross-theme axe regression suite
element-hq/element-web#34468	❌ Closed by maintainers	Submenu hover-out dismissal — included because being rejected is instructive

Best Use of Sentry

(Taking this section out of template order deliberately — it's the substance of the submission.)

Sentry tools used

Error Monitoring — the integration pipeline itself (Sentry.init, integration list, processEvent)
Source Maps / Releases & Artifacts — artifact path matching, which is what was actually broken
Issue Grouping — restoring cross-platform grouping between desktop and web
A live Sentry project — used as the verification harness, firing an identical fabricated crash through both configs and diffing the resulting issues

I'm not claiming Session Replay, Distributed Tracing or Seer. I didn't use them. What I did was repair the layer everything else in Sentry sits on: if your frames don't resolve, nothing downstream of them is trustworthy either.

Root cause: an opt-out that silently freezes in time

apps/web/src/sentry.ts initialises Sentry with defaultIntegrations: false and a hand-picked list:

const integrations = [
    Sentry.inboundFiltersIntegration(),
    Sentry.functionToStringIntegration(),
    Sentry.breadcrumbsIntegration(),
    Sentry.httpContextIntegration(),
    Sentry.dedupeIntegration(),
];

defaultIntegrations: false is the actual root cause, and it's worth dwelling on because it's a pattern lots of apps have.

It's chosen for good reasons — bundle size, no surprise behaviour, explicit is better than implicit. But it converts "you get sensible defaults" into "you get exactly this list, forever." When the SDK ships a new integration, or when your app grows a deployment target that would have needed one, nothing tells you. There is no warning, no deprecation, no failing test. The list just quietly stops describing what you need.

rewriteFramesIntegration was never on that list. So frames went to Sentry exactly as the Electron renderer produced them, custom protocol and all.

The fix

Eight lines:

// Element Desktop serves the app from the custom `vector://vector/webapp` origin rather
// than a normal web origin, so its stack frames don't match Element Web's and end up
// ungrouped and unsymbolicated. Normalize both to the same relative form so desktop
// crashes group with, and source-map against, the same release as the web app.
Sentry.rewriteFramesIntegration({
    root: "vector://vector/webapp",
    prefix: "app://",
}),

app:// is Sentry's documented convention for custom-origin apps — the pattern Sentry's own Electron guidance uses. It's a no-op for Element Web, whose frames never start with that prefix, which is what makes this safe to ship globally rather than gating it behind a platform check.

The two-character detail that would have shipped a fake fix

prefix: "app://". Two slashes. Not three.

This looks like bikeshedding. It isn't, and it's the part of this PR I'd defend hardest.

Here's what rewriteFrames actually does to a filename. It strips root off the front:

vector://vector/webapp/bundles/abc123/bundle.js
─────── root ────────┘

leaving /bundles/abc123/bundle.js — with the leading slash still attached. Then it prepends prefix.

So prefix: "app://" gives you the canonical app:///bundles/abc123/bundle.js. But the string app:/// is what you see in every Sentry doc and every Stack Overflow answer, so writing it into the config is the natural mistake. Do that and you get:

app:////bundles/abc123/bundle.js

Four slashes. And here's why that's genuinely dangerous rather than merely wrong: it fails completely silently. Sentry accepts the event. The issue appears in your dashboard. The stack trace renders. The paths even look plausible at a glance. The only symptom is that artifacts still don't match — so you'd have closed a four-year-old issue, told the maintainers it was fixed, and swapped one broken path for a differently broken path that nobody would notice for months.

There is no error message anywhere in that failure mode. The only defence is asserting on the output.

So I tested the output, not the config

Most tests of a Sentry integration check that it's wired up. Mine does that — and then does the thing that actually matters.

Layer 1: mocked SDK — is the integration wired in?

jest.mock("@sentry/browser", () => ({
    init: jest.fn(),
    inboundFiltersIntegration: jest.fn().mockReturnValue({ name: "InboundFilters" }),
    functionToStringIntegration: jest.fn().mockReturnValue({ name: "FunctionToString" }),
    breadcrumbsIntegration: jest.fn().mockReturnValue({ name: "Breadcrumbs" }),
    httpContextIntegration: jest.fn().mockReturnValue({ name: "HttpContext" }),
    dedupeIntegration: jest.fn().mockReturnValue({ name: "Dedupe" }),
    rewriteFramesIntegration: jest.fn().mockReturnValue({ name: "RewriteFrames" }),
}));

it("normalizes Element Desktop's vector:// stack frames so they group with Element Web", async () => {
    await initSentry({ dsn: "https://examplePublicKey@o0.ingest.sentry.io/0", environment: "test" });

    expect(Sentry.rewriteFramesIntegration).toHaveBeenCalledWith({
        root: "vector://vector/webapp",
        prefix: "app://",
    });

    const { integrations } = jest.mocked(Sentry.init).mock.calls[0][0]!;
    expect(integrations).toEqual(expect.arrayContaining([{ name: "RewriteFrames" }]));
});

This guards against the defaultIntegrations: false failure mode repeating — if someone edits that array later and drops the integration, this fails. Given that the original bug was "something isn't in the integrations list," a regression test on the list itself is the right shape.

Layer 2: the real SDK — what string actually comes out?

describe("rewriteFramesIntegration output", () => {
    // Uses the real Sentry SDK integration (not the mock above) to verify the actual rewritten
    // path, since it's easy to get the exact prefix/slash count wrong (e.g. `app:///` here would
    // double up with the leading slash already present in the frame, producing `app:////...`).
    // Relies on this test file's jsdom environment providing a real `window`, which is what makes
    // the SDK's browser root/prefix substitution apply in the first place.
    it("rewrites a vector:// frame to a clean app:/// path", async () => {
        const RealSentry = jest.requireActual<typeof Sentry>("@sentry/browser");

        const integration = RealSentry.rewriteFramesIntegration({
            root: "vector://vector/webapp",
            prefix: "app://",
        });

        const event: any = {
            exception: { values: [{ stacktrace: { frames: [
                { filename: "vector://vector/webapp/bundles/abc123/bundle.js" },
            ] } }] },
        };

        const processed = integration.processEvent!(event, {}, {} as any) as any;
        expect(processed.exception.values[0].stacktrace.frames[0].filename)
            .toBe("app:///bundles/abc123/bundle.js");
    });
});

jest.requireActual pulls the genuine @sentry/browser past the mock, so this drives Sentry's real processEvent pipeline with a hand-built event and asserts the exact resulting filename — every slash of it.

A mock-only suite would pass forever with app:/// sitting in the config. That's the whole argument for layer 2: test the observable output of the SDK, not your belief about what you configured.

The comment about jsdom is load-bearing too. rewriteFrames' root/prefix substitution branch only applies when it detects a browser environment via a real window. Run this under a node test environment and the assertion silently stops testing what you think — so the reason it works is written down for whoever touches it next.

Verified against a real Sentry project

Unit tests prove the transform. They don't prove Sentry's ingestion agrees with you. So before opening the PR I sent an identical fabricated crash through both configs — pre-fix and post-fix — into a live Sentry project, and compared the resulting issues side by side. Before/after screenshots are in the PR description.

That step is what turned "this should work" into "I watched it work," and it's what I'd insist on for any change to error-reporting plumbing. Observability code is uniquely bad at telling you when it's broken, because its failure mode is producing something that looks like data.

Answering the question that had been open since 2021

I originally scoped novocaine's second point out. The PR said so explicitly:

This PR addresses the path-prefix normalization only; the bundle-hash discrepancy is a separate, unrelated build/packaging question this PR doesn't investigate.

Then @t3chguy dropped a hint in review:

Back in '21 the build system was probably significantly different, nowadays the desktop build process literally downloads the release asset in the fetch script

So I went and read apps/desktop/scripts/fetch-package.ts. The modern desktop build pulls element-<version>.tar.gz directly from the GitHub release and repacks that exact tarball into webapp.asar. It doesn't build its own bundle at all.

Which means the bundle hash can't diverge any more — the hash mismatch novocaine saw was an artifact of the 2021 pipeline, and that pipeline is gone.

And that materially changes what this PR does. If the hashes still differed, stripping the vector:// prefix would only have fixed symbolication. Because they don't, once the prefix is normalised the remaining path — hash included — is identical to the web app's frames for the same release. So the fix closes both halves of the original report:

	Before	After
Desktop stack traces	Minified, unsymbolicated	Source-mapped against the release
Same crash on desktop + web	Two unrelated Sentry issues	One issue, correct event volume
Issue #32242	Open since Nov 2021	Closed

Twenty minutes of reading a build script. That's the difference between closing a symptom and closing an issue — and between "here's a patch" and "here's the answer to the thing you asked in 2021."

Merged via the merge queue on 12 August 2026, 46 checks passing.

My Improvements

(Template section — the Sentry deep dive is above; this covers the second merged fix.)

The accessibility bug: a token that means the opposite thing in a different theme

My first instinct on #34213 was a missing hover colour. Wrong — the colour was there and it was deliberate:

.mx_SpotlightDialog_option {
    &:hover,
    &[aria-selected="true"] {
        background-color: $quinary-content !important;
        color: $background !important;   /* ← the bug */
    }
}

$background is the theme's canvas colour; $quinary-content is the hover fill. In a dark theme this is correct — the hover pill is light, $background is dark, you get dark text on a light pill. In light-high-contrast, $background is white-ish. So is $quinary-content. Same rule, inverted theme, invisible text.

This is a semantic-token failure, not a typo, which is why it survived review for so long. color: $background reads as intentional. It's only wrong once you know what the token resolves to in that specific theme. The correct token for "the theme's readable text colour" is $primary-content — changed in 12 places across search results, recently-viewed rows, the filter chip, the keyboard-shortcut hint and the generic dropdown menu.

The !important on nearly every one of those lines is its own signal. Rules that needed !important were fought into place, and rules that were fought into place don't get re-derived when someone adds a new theme.

Widening the test caught a second, unreported bug

My first test computed the WCAG ratio by hand in Playwright — 1.38:1 before, ≥4.5:1 after. t3chguy pushed me to use axe-core instead, and he was right for a reason I'd underweighted: my version only checked the four elements I thought to check. It was a spot check wearing the costume of a general one.

Then @Half-Shot pushed further — don't test only high contrast:

for (const theme of ["light", "dark", "light-high-contrast"]) {
    test.describe(`${theme} theme legibility`, () => {
        // Regression tests for https://github.com/element-hq/element-web/issues/34213
        // Hovered/selected Spotlight results must not render light text on a light
        // background (or vice versa) in any theme, not just high contrast ones.

Running axe against the ordinary light and dark themes flagged that publicRoomAlias and publicRoomDescription, styled $secondary-content / $tertiary-content, also failed 4.5:1 against the hover background. Not in high contrast. In the themes essentially everyone uses. That became a second fix in the base stylesheet.

The reported bug was one theme. The real bug was "hover states in this dialog were never contrast-checked against anything."

I also scoped something out: axe surfaced a pre-existing nested-interactive violation (focusable end-adornments inside clickable rows). Real problem, unrelated to colour, would have meant restructuring markup in a PR about a colour token. So — axe.disableRules("nested-interactive") with an XXX comment naming exactly why. A named exclusion with a reason is a signpost; a silent one is a bug you hid.

Getting it green took three rounds of CI. Invalid // comments in a .pcss file crashed the Oxfmt parser. Then a screenshot baseline failed — and failed again after I regenerated it locally, with a 418px diff, because the baseline is filtered-one-result-linux.png and the -linux is a contract, not a label. Font rendering differs between my machine and the CI runner. Committing the image CI itself produced was the fix.

Final: 12 commits, +83 −12, 4 files, merged 13 August 2026.

Coda: the fix that was correct and still got rejected

PR #34468 is closed, and that's why I'm including it.

Element's room-list submenu opens on hover but never closes on hover-out. Radix's dropdown primitives close a submenu on click-outside, Escape, item selection, or hovering a sibling trigger — pointer leaving and idling elsewhere isn't a recognised trigger. I tracked pointer position against both trigger and content and closed only the submenu after a 300ms grace period, tested in real Chromium via @vitest/browser-playwright because Radix's pointer machinery genuinely doesn't behave under jsdom.

@Half-Shot flagged something I hadn't weighed: time-based auto-dismissal can be an accessibility problem, and his OS/browser doesn't do this for submenus at all. He took it to Element's design team, who judged it a step back for mouse users. Closed.

Another user disagreed in the thread — the submenu opens on hover, so persisting outside hover is inconsistent, and there's no way to dismiss just the submenu. I think he's right. I also think the call belongs to the maintainers. Correct code and correct product are different judgements, and in someone else's repo only the first one is mine.

Takeaways

defaultIntegrations: false has a maintenance cost nobody budgets for. You've opted out of every future SDK improvement, silently, forever. If you use it, put a calendar reminder on reviewing that list.

Observability bugs are the worst kind, because broken instrumentation still produces output. A four-slash path renders a perfectly convincing Sentry issue. Assert on the exact output string, using the real SDK — not on your config.

Grouping failures are more expensive than symbolication failures. Unsymbolicated crashes are annoying. Split crashes distort which bugs you fix.

Read the build script. The unanswered question in a five-year-old issue was answerable in twenty minutes, and answering it turned a partial fix into a complete one.

Semantic tokens carry meaning, not values — and meaning flips across themes. If your design system has themes, contrast belongs in CI.

Widen the test before you narrow the fix. Three themes instead of one found a bug nobody had reported.

Credits

To @novocaine, who wrote a bug report in 2021 so precise that it named the fix — and was honest enough to flag the part he couldn't explain. Five years later, that report was still the best documentation of the problem.

To the Element maintainers who reviewed these as community PRs: @t3chguy, whose one-line aside about the fetch script is the reason this PR closes the whole issue instead of half of it, and who told me three separate times that CI was still red; @Half-Shot, whose "test all the themes" note directly caused the second contrast bug to be found, and who escalated the submenu change to design rather than rubber-stamping it; and @americanrefugee and @dbkr for review and triage.

Thanks to Sentry for rewriteFramesIntegration and for documenting the custom-origin pattern clearly enough that a 2021 bug reporter could link to the right page from memory.

Element Web is AGPL-3.0 and takes community contributions seriously — the review I got on an eight-line config change was better than most people get on features. Their Good First Issue list is a genuinely good place to start.

From a 15-Second Walk to a Digital Memory: Building a Canine Cognitive Twin

Prince Panchani — Mon, 17 Aug 2026 01:05:55 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Canine Cognitive Twin — a living digital twin for a dog.

A dog owner uploads a short morning-walk video directly from the browser. Gemini analyses the video and returns structured observations plus first-person narration. ElevenLabs turns that narration into the dog's voice. Snowflake Dynamic Tables transform individual observations into a longitudinal baseline, while Cortex identifies potential gait drift that may be difficult to notice manually. Solana records each chapter with a content hash and anomaly flag.

The result is more than a video analyser:

One walk becomes one chapter in a digital memoir — with a longitudinal behavioural record and an ownership/proof layer.

Not a veterinary device. Not diagnostic. Consult a veterinarian.

Demo

🎥 Live Demo

💻 Source Code

View the Canine Cognitive Twin repository on GitHub

Demo Status

The demo demonstrates the implemented end-to-end architecture while clearly distinguishing live processing from synthetic historical data used for anomaly detection.

The browser upload, Gemini analysis, ElevenLabs narration, Snowflake pipeline, anomaly detection, dashboard, and Solana recording are implemented as separate services connected through the ingestion pipeline.

Historical gait data used to establish the anomaly-detection baseline is intentionally synthetic and is explicitly labelled as SYNTHETIC HISTORY in the dashboard.

Implemented Pipeline

Step	Technology	Purpose
Browser video upload	React + Vite	Allows the owner to upload a dog-walk video directly from the browser
Video analysis	Gemini 3 Pro	Extracts behaviour tags, gait asymmetry, emotion, and first-person narration
Structured output	Gemini `responseSchema`	Keeps model output predictable and machine-readable
Text-to-speech	ElevenLabs Flash v2.5	Converts the dog's narration into speech
Data processing	Snowflake Dynamic Tables	Transforms raw observations into cleaned events and longitudinal summaries
Anomaly detection	Snowflake Cortex	Detects potential gait drift against historical patterns
Dashboard	Streamlit in Snowflake	Presents the dog's memoir and health-radar style insights
Immutable record	Solana Devnet	Records chapter index, content hash, and anomaly flag
Ownership layer	Solana PDA	Gives each dog a persistent on-chain identity

Synthetic Data Disclosure

Anomaly detection requires a historical baseline. A single video capture cannot establish meaningful longitudinal behaviour, so the repository includes generated history for demonstration and development.

Data	Status	Reason
90 days of gait/vitals history	Synthetic	Required to establish a baseline for anomaly detection
Injected gait drift around day 60	Synthetic	Demonstrates that the anomaly pipeline can identify a change from baseline
Voice Design voice	Pre-configured	Designed once and reused as the dog's consistent voice persona
Sound effects	Pre-rendered	Sniffing, panting, collar jingles, and environmental sounds are prepared ahead of time
Gemini fallback response	Development fallback	Prevents a temporary API/rate-limit failure from stopping the demo

The synthetic history is generated by snowflake/generate_synthetic_history.py.

Every dashboard panel relying on generated historical data is explicitly marked with a SYNTHETIC HISTORY badge.

There is no intentional blending of synthetic historical data with live observations without disclosure.

Architecture

The end-to-end data flow is:

React Web App
      │
      │ Browser video upload
      ▼
Cloudflare Worker
      │
      ├──► Supabase Storage
      │       └── Media storage
      │
      ├──► SHA-256
      │
      └──► Gemini 3 Pro
              │
              ├── behavior_tags
              ├── gait_asymmetry_score
              ├── emotion
              └── narration
                    │
                    ▼
             ElevenLabs
                    │
                    ▼
              Web App Playback

Gemini Result
      │
      ▼
Snowflake RAW_EVENTS
      │
      ▼
Dynamic Tables
      │
      ├──► CLEANED_EVENTS
      │
      └──► DAILY_SUMMARY
                │
                ▼
      Snowflake ML Anomaly Detection
                │
                ▼
          GAIT_ANOMALIES
                │
                ▼
      Streamlit-in-Snowflake
         ├── Memoir
         └── Health Radar
                │
                ▼
          Oracle Relay
                │
                ▼
          Solana Devnet
         record_memory

Why I Made These Architecture Decisions

Browser Upload Instead of a Mobile App

The final implementation uses a browser-based upload flow instead of requiring a separate mobile application.

This makes the experience immediately accessible:

Open the web app → upload a dog-walk video → watch the cognitive twin process it.

The browser sends the video to the Cloudflare Worker, which becomes the entry point for the processing pipeline.

Oracle Relay Instead of Direct Snowflake Signing

Snowflake Dynamic Tables cannot directly sign Solana transactions or freely call arbitrary external APIs.

Instead, a lightweight oracle-relay polls Snowflake's V_ORACLE_PAYLOAD, signs the transaction, and submits it to Solana Devnet.

This keeps blockchain operations outside the main Gemini + TTS request path, so a slow blockchain transaction does not block the user-facing processing pipeline.

The Anchor program still verifies the oracle public key on-chain.

Separate Runtime Implementations

The ingestion worker runs inside the Cloudflare Workers runtime, while the oracle relay runs in Node.js with tsx.

Although both components use keypair-based authentication, their runtime crypto APIs and execution environments differ. Keeping them separate avoids introducing an abstraction purely to unify two different runtime environments.

Fallback Instead of Silent Failure

External AI APIs can fail because of rate limits or temporary availability issues.

Instead of silently pretending the response was generated live, the worker can load a pre-recorded Gemini response when the live request fails.

The response explicitly contains:

{
  "source": "fallback"
}

This allows the dashboard and pipeline to communicate the state rather than hiding it.

Prize Technology

Technology	Used For	Why It Matters
Google AI / Gemini	Multimodal video analysis, schema-constrained JSON, and contextual reasoning	Provides the actual observation and interpretation layer
Snowflake	Dynamic Tables, historical baselines, Cortex anomaly detection, and Streamlit	Turns individual observations into longitudinal intelligence
ElevenLabs	Voice Design, Flash v2.5 narration, and sound design	Gives the digital twin a consistent personality and voice
Solana	Dog identity and immutable memory records	Adds an ownership and proof layer outside a centralised application database

These technologies are not decorative integrations.

Each one has a specific role in the product:

Gemini → Observe & Understand

Snowflake → Remember & Detect Change

ElevenLabs → Give the Twin a Voice

Solana → Own & Prove

Code

PrinceXDev / dog-day-edition

Canine Cognitive Twin

A living digital twin for a dog. An owner uploads a clip of a morning walk from the browser; Gemini reads the video and returns structured observations plus a first-person narration; ElevenLabs speaks it; Snowflake Dynamic Tables fold it into a rolling baseline; Cortex flags gait drift the eye would miss; Solana records the chapter under the owner's own keys.

Not a veterinary device. Not diagnostic. Consult a veterinarian.

New here and just want to get something running? Jump to Quick start.

What is live vs. what is synthetic

This table is the first thing in the repo on purpose. Everything below the line is generated, and it is labeled generated on screen too.

Live — clicked during the demo, nothing faked

Step	Tech	Latency
Owner uploads a video of a walk from the browser, straight to the Worker	React + Vite web app	~5s
Video

…

View on GitHub

canine-cognitive-twin/
├── snowflake/          Dynamic Tables, Cortex anomaly model, Streamlit app
├── gemini-pipeline/    Schema-constrained Gemini analysis
├── elevenlabs-service/ Voice Design, narration, SFX
├── ingestion-worker/   Cloudflare Worker: Supabase → Gemini → Snowflake → TTS
├── oracle-relay/       Snowflake → Solana transaction relay
├── solana-program/     Anchor program for dog identity and memories
├── web-app/            React + Vite browser application
└── demo-assets/        Fallback response and demo assets

What's Next

The current implementation establishes the core pipeline from video → observation → narration → longitudinal analysis → immutable memory.

The next milestones would be:

Owner-facing export of the memoir and on-chain proof
Multi-dog households with one Solana wallet and a PDA per dog
Per-dog voice calibration
Longer-term behavioural and mobility trends
More advanced gait and movement visualisations
Additional behavioural signals beyond gait
Stronger owner-facing explanations around detected changes
Continuous longitudinal learning from real owner-approved captures

Prize Categories

I'm submitting this project for:

Best Use of Snowflake
Best Use of Solana
Best Use of ElevenLabs
Best Use of Google AI

The goal wasn't simply to combine four technologies.

Each technology solves a different part of the same problem:

Observe → Understand → Remember → Give a Voice → Prove

Final Note

I wanted the project to demonstrate something more meaningful than a simple AI video analyser.

A single video can describe what a dog is doing right now.

A cognitive twin should be able to understand what is changing over time.

That's why the architecture combines multimodal AI, longitudinal data processing, anomaly detection, voice, and an ownership layer.

The final experience is intentionally simple:

Upload a walk. Let the twin understand it. Turn it into a memory. Track what changes over time. Keep the record under the owner's control.

Thanks for reading. 🐶

The 2 A.M. Fridge: A Landing Page With Exactly One Light Source

Prince Panchani — Mon, 10 Aug 2026 10:30:17 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

🍕 What I Built

Most "comfort food" landing pages are going to show you a hero shot of steam rising off a bowl of ramen, a warm colour palette, maybe a parallax scroll. I wanted to build the opposite of that: a page with almost no light in it, where the only thing you can see is whatever you choose to open.

The 2 A.M. Fridge is a single page. It's pitch black. There's a fridge door in the middle of the screen, closed. You pull the tab, the door swings open, and a rectangle of cold light spills into the kitchen — and that's the entire lighting model for the rest of the experience. Nothing else on the page is lit except what the fridge illuminates.

The concept came from a very specific, very unglamorous kind of comfort: not the food itself, but the ritual of standing in front of an open fridge at 2 a.m., not really hungry, just looking. So instead of a menu or a hero pitch, the page is structured as five "acts" — top shelf, middle shelf, the drawer, the freezer, and a hidden jar pushed to the back — and every item you find has a short piece of fiction attached to it. Someone else's mustard, three-day-old curry, a jar of stock made in a good week for a bad one. Nothing dramatic. Just the small, specific stories that live in everyone's fridge.

The technical decision that everything else hangs off: the whole scene is driven by one CSS custom property.

@property --light-intensity {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

As you drag the pull-tab (or press Enter/Space on it — more on that below), fridge-door.ts updates --light-intensity from 0 to 1. That single number feeds the lightwell's radial-gradient glow, the door outline's filter: brightness(), every shelf item's cast shadow, and the condensation overlay's opacity. One value, read in one place, drives the entire visual state of the page. No shadow maps, no lighting engine — just a number and a handful of CSS consumers that all agree on what it means.

The interactions I'm most proud of aren't the obvious ones:

The fridge door has real spring physics, not a CSS transition easing curve. There's a tiny critically-damped spring integrator (spring.ts, no dependencies) that also powers a "nudge" effect — hover over a shelf item and its neighbours flinch slightly, like you bumped the shelf.
Shelf items are a real 2D grid widget. Arrow keys move focus row-to-column, Home/End jump to the ends, and only the focused item sits in the tab sequence (roving tabindex). It's not a <div> soup pretending to be interactive.
The jar pushed to the back of the freezer is a two-step micro-puzzle — move the ice tray, move the bag of peas, then the jar becomes reachable. It holds the emotional peak of the whole piece (a broth someone's grandmother made "for a day she must have known she might not be there for"), and it's built from three ordinary buttons. No drag, no timing window, no pointer-only trap.
The closing line is emergent, not fixed. There are about ten hand-written closing sentences, and which one you see depends on what you actually did — did you find the jar, did you close the door and reopen it, did you never touch a mouse, did you linger longest at the freezer. It's a pure decision tree over signals tracked in memory for that visit only. Nothing is sent anywhere, nothing persists.

None of this needed a framework to do the heavy lifting. It's Astro, TypeScript, and vanilla DOM/CSS — the LCP element (the fridge door) is server-rendered HTML/CSS with zero JS required to paint it, and everything animated only ever touches transform/opacity/filter. backdrop-filter never gets driven by a scroll or state variable on purpose — it's one of the most expensive properties you can animate, and this page didn't need to prove a point by using it.

🚀 Demo

Live Demo: https://the-2-am-fridge.netlify.app/

Please actually open the fridge door instead of just scrolling past it — drag the pull-tab, or tab to it and hit Enter. Go through all five acts. Hover over a shelf item to see the neighbour-nudge. Find the jar at the back of the freezer (you'll need to move two things first). Try the "Turn on the kitchen light" toggle in the header, which flips the entire page to a fully lit, 7:1-contrast layout using the exact same design tokens, not a separate theme bolted on. Then close the door and see what the closing line says about your visit.

GitHub: https://github.com/PrinceXDev/perfect-landing-comfort-food

If you want to see how it's actually wired together, src/scripts/fridge-door.ts and src/scripts/spring.ts are the two files that do the most with the least code.

🧑‍💻 Journey

I didn't start with "let's build a dark UI." I started with the idea that the most honest comfort-food story isn't a recipe, it's the fridge itself — specifically what's still in it that nobody's dealt with. Once I had that, the constraint fell out naturally: if the fridge is the only story, the fridge should be the only light.

That constraint turned out to be the best thing that happened to the build, because it forced every decision through one question — does this need light, or can it stay dark? The hero heading is visually hidden (there's nothing to read in pitch black, just a floating pull-tab and a timestamp). The condensation effect on the shelf glass runs through an SVG feTurbulence filter rather than a canvas or WebGL trick, because it only needed to look right inside a small lit rectangle, not do anything clever at scale.

The hardest part wasn't the visuals — it was making sure the darkness didn't become an accessibility liability. It's easy to build a moody dark UI that's a nightmare for anyone using a screen reader, reduced motion, or keyboard-only navigation. I didn't want the "experience" to be a tax paid only by sighted mouse users, so I wrote a whole /accessibility page documenting the actual decisions, not a boilerplate statement:

The drag-to-open door has a non-dragging equivalent (WCAG 2.5.7) — Enter/Space fully opens or closes it.
Motion respects prefers-reduced-motion and a persisted on/off toggle, implemented as a real CSS state (html[data-motion]), not a one-time sweep of running animations — a sweep misses requestAnimationFrame loops and SVG SMIL entirely. The condensation filter's SMIL <animate> specifically needed SVGSVGElement.pauseAnimations() because CSS media queries can't reach into an SVG filter.
forced-colours: active (Windows Contrast Themes) is handled deliberately: since the OS overrides colours regardless of what I author, the decorative light/shadow/condensation layers are hidden outright instead of rendering unforced on top of a forced palette.
Every interactive target clears the 24×24px minimum (WCAG 2.5.8), verified on an iPhone 13 viewport in Playwright.

Writing that page after the fact, rather than bolting accessibility on as an afterthought, changed how I thought about the "emergent epilogue" feature too. The keyboard-only branch of the closing line exists because a keyboard-only visitor does something measurably true — no pointerdown ever fires, but real input clearly did — so the accessibility work became part of the story itself instead of a separate feature to demo.

The other genuinely hard problem was performance discipline against my own worst instincts. It would have been very easy to reach for backdrop-filter for the frosted-glass condensation look, or to run the shelf-nudge spring loop continuously "just in case." Instead, the spring loop starts on requestAnimationFrame only when nudged and kills itself (rafId = null) the instant every item has settled, and I kept the animated set strictly to properties the compositor can handle cheaply.

I write the shelf and freezer stories almost like flash fiction — a few sentences, an interior monologue, no exposition. That took longer than any of the code. Getting a hidden jar of a grandmother's broth to land emotionally in two sentences, gated behind an actual puzzle instead of just appearing, was the part I rewrote the most.

What I'd improve next: the README is upfront about this — there's no art direction or photography pass yet (it's a deliberately text-only build), fonts are still the system stack rather than self-hosted and subset, and the mobile pass covers touch/viewport correctness but hasn't had the same interaction polish as desktop pointer events. If I kept going, next would be a proper mobile drag gesture for the door, and maybe extending the "one custom property drives everything" idea to a subtle day/night cycle based on the visitor's actual local time.

What I learned, more than anything: constraints are a gift. "The fridge is the only light source" sounds like it limits what you can build. In practice, it made almost every design decision obvious, because there was always a clear test — does this need the light, or does it live in the dark.

If you try it, I'd genuinely like to know which shelf item got to you, and whether you found the jar. Open the fridge, poke around, and if something breaks or the accessibility claims above don't hold up — file an issue, that page says as much itself.

Tags: #webdev #javascript #astro #accessibility #showdev

139,907 Calls Later: What It Actually Takes to Port a Numerical Library from JavaScript to Rust

Prince Panchani — Mon, 10 Aug 2026 05:47:44 +0000

139,907 Calls Later: What It Actually Takes to Port a Numerical Library from JavaScript to Rust

Porting a library between languages is mostly a typing exercise until the output has to be exactly the same.

For most code, "the same" has slack in it. A web handler that returns the right JSON with the fields in a different order is fine. A parser that produces an equivalent AST with different node names is fine. But when you port an arbitrary-precision arithmetic library, there is no slack. "5e-8".toFixed(2) is either "0.00" or it is wrong. There is no third answer, no "close enough," no reviewer who will accept 0.01 because the algorithm is morally correct.

I spent the back end of the Code Resurrection window rebuilding MikeMcl/bignumber.js — about 2,520 lines of JavaScript — in Rust. The interesting part of that work was not writing Rust. It was the fourteen separate occasions where I was confident the port was correct, and ~140,000 captured calls from the original library's own test suite disagreed with me.

This is the write-up of what broke, how I found it, and the one decision I'd take back.

The project I chose

Code Resurrection 2026 frames porting as digital archaeology: you don't just move code across a language boundary, you excavate what the original actually promised and carry those promises forward. The framing matters more than it sounds like it does, and I'll come back to why.

I picked bignumber.js off the JavaScript → Go/Rust track for a reason that turned out to be the whole story: it is a library whose entire value proposition is that its output is exact. Most candidate projects let you argue about fidelity. This one doesn't. Either my dividedBy returns the same digits as the original's dividedBy for every input, or my port is a different library that happens to have the same method names.

That gave me something rare in a porting project: an unambiguous, mechanically checkable definition of "done."

What bignumber.js is for

The canonical demo:

0.1 + 0.2
// 0.30000000000000004

This isn't a JavaScript bug; it's IEEE 754. A binary floating-point f64 has 53 bits of mantissa and stores values as a binary fraction. 0.1 and 0.2 are not representable in binary any more than 1/3 is representable in decimal — you get the nearest f64, and the error surfaces when you add them.

For graphics or physics, that's invisible. For money, tax, or anything that reconciles against a ledger, it's a defect. bignumber.js exists to give JavaScript a number type that stores decimal digits as decimal digits:

new BigNumber(0.1).plus(0.2).toString()
// "0.3"

The library covers arbitrary-precision decimal arithmetic, nine rounding modes, configurable precision and exponential-notation thresholds, non-decimal bases, and a formatting layer. It's ~2,520 lines, MIT-licensed, and has been load-bearing infrastructure in the JS ecosystem for over a decade.

Which raises the obvious question for a port: what, exactly, is the specification?

The archaeology: the source code was the smaller half of the artefact

Here is the thing I did not expect, and it reframed the whole project.

bignumber.js ships ~2,520 lines of implementation. Its test suite is 47,713 lines containing 65,727 assertions across 34 files. The tests are nineteen times larger than the thing they test.

That ratio is not an accident, and it is not over-testing. It is the actual shape of the specification. The implementation tells you how the library computes; the test suite tells you what it promises — and for a numerical library, the promises live almost entirely in the edges:

What does toFixed do when the rounding position falls before the first stored digit?
What is the sign of a zero, and which methods preserve it versus drop it?
What happens to HALF_EVEN when the tie-break digit is the last one and rounding up grows the digit count?
Does Math.pow(1, NaN) return 1 or NaN?

None of those is answered by reading round(). All of them are answered by the tests.

My original plan was to hand-translate each of the 34 test files into Rust #[test]s. Once I actually measured the suite — 47,713 lines — that plan was dead. Not just infeasible in the time I had, but lower value than the alternative, and this is the decision I'm most glad I made:

Instead of re-stating the original's tests in Rust, I ran the original's tests for real and recorded everything they did.

The harness (fuzz/capture_tester.js) monkey-patches BigNumber.prototype purely to observe — it doesn't alter behaviour — and captures, for every single call the real suite makes:

{ method, receiver, args, result, activeConfig }

That produced 139,907 real calls. Those get replayed against the Rust port by src/bin/replay_captured.rs and diffed.

The activeConfig field is there because of a genuine archaeological finding. BigNumber.config() is a global mutable state in JavaScript — it lives in variables closed over by the clone() factory. That means config leaks across test files loaded later in the same process. A call in toFixed.js might execute under a DECIMAL_PLACES set by a file that ran twenty minutes earlier. If you replay those calls under the default config, you get hundreds of false divergences, and you'll spend a day chasing bugs that don't exist. Capturing config per-call was not a nicety; it was the difference between a usable signal and noise.

One honest footnote, because it belongs in the record: instrumenting the prototype costs 12 assertions inside the JS suite itself — 65,715 pass under capture versus 65,727 unmodified. It's almost certainly a wrapper interaction with squareRoot's internal t.times(t).eq(x) self-comparison, not a defect in bignumber.js. I documented it rather than quietly rounding it away.

A port is not a translation

The gap between JavaScript and Rust that mattered here was almost never syntax. It was semantics, and the semantics hid in four places.

Null is three different things. JS stores a BigNumber as {s, c, e} — sign, coefficient limbs, exponent — and uses null in each field to encode special values. s: null means NaN. c: null with a non-null s means ±Infinity. Rust has no null, so the port models this as:

pub struct BigNumber {
    /// `Some(1)` positive, `Some(-1)` negative, `None` = NaN.
    s: Option<i8>,
    /// Coefficient limbs, base 1e14, most-significant first. `None` = ±Infinity or NaN.
    c: Option<Vec<i64>>,
    /// Base-10 exponent of the most significant digit.
    e: Option<i64>,
}

I deliberately did not collapse this into the enum every Rust reviewer's instinct reaches for:

enum BigNumber { Finite { .. }, Infinite(Sign), NaN }   // the tempting version

That enum is better Rust. It is also a rewrite, not a port. Nearly every original algorithm — round, div, normalise, compare — branches on the specific null/non-null combinations of s/c/e, in an order that depends on exactly this shape. Re-deriving equivalent branching against a cleaner enum means re-proving each algorithm's correctness from scratch instead of porting it. With a hard deadline and a correctness bar of "byte-identical," that trade was not closed.

Global mutable config doesn't survive the crossing. JS's BigNumber.config() mutates closure-captured module state shared by every instance from that constructor. Rust has no natural equivalent, and faking one with a static mut or a lazy global would import the original's biggest weakness — the original is not thread-safe; you need two separate BigNumber.clone() factories to get independent config in one process. So the port threads config explicitly:

x.plus(&y, &cfg)      // instead of x.plus(&y) reading a global

More idiomatic, trivially thread-safe, and a disclosed divergence: BigNumber.config()/.set() are consequently not ported as such. That's in DECISIONS.md, not buried.

JavaScript's Math.pow is not IEEE 754. This one costs real time. exponentiatedBy has a float-fallback path for NaN/±Infinity/±1/±0 operands, and Rust's f64::powf disagrees with JS in exactly two places:

Math.pow(x, NaN) is always NaN in JS. Rust's powf special-cases base 1.0 and returns 1.0 even for a NaN exponent.
Math.pow(±1, ±Infinity) is NaN per ECMA-262's Number::exponentiate — a deliberate JS-specific deviation from C99 pow, which defines it as 1.

Without a wrapper, BigNumber(1).exponentiatedBy(NaN) returned 1 instead of NaN — and worse, it propagated silently through the modular form, where the wrong 1 fed into .modulo(m) and produced 0 instead of a NaN. The fix is nine lines, and every one of them is a language-semantics fact, not an arithmetic one:

fn js_math_pow(base: f64, exponent: f64) -> f64 {
    if exponent.is_nan() {
        return f64::NAN;
    }
    if (base == 1.0 || base == -1.0) && exponent.is_infinite() {
        return f64::NAN;
    }
    base.powf(exponent)
}

Errors move from throw-sites to type signatures. JS throws Error('Exponent not an integer: ' + n) from anywhere. In Rust, that has to become Result<BigNumber, BigNumberError>, which changes the signature, which changes every caller. Two of my fourteen bugs were missing error paths — places where JS validated, and I hadn't, so instead of an error, the port returned a wrong answer or hung.

What the number actually is

BigNumber
├── s : sign        Some(1) | Some(-1) | None (NaN)
├── c : coefficient Vec<i64> of base-1e14 limbs, most-significant first
│                   None = ±Infinity or NaN
└── e : exponent    base-10 exponent of the most significant digit

Base 1e14 is the original's choice, and I kept it: it's the largest power of ten whose products stay inside JS's 2^53 safe-integer range when split via a 1e7 half-base during multiplication. Carrying that constant across meant carrying the exact same overflow boundaries, which meant carrying the exact same results.

Two internals I did rewrite, both consciously:

round() operates on a flat digit string, not limb indices. The original tracks, which base-1e14 limb the rounding digit falls in plus its offset within that limb (ni, i, j, d in the JS source). It's correct, and it's fast. My direct transliteration produced a genuine borrow-checker conflict and several off-by-one bugs before I scrapped it. The Rust version flattens the coefficient to a digit string, makes the rounding-mode decision and carries there, then rebuilds limbs aligned to the resulting exponent. Same observable semantics — verified against Node ground truth across all nine rounding modes, including HALF_EVEN's odd/even tie-break and carry-driven digit-count growth — different mechanism.

Division is schoolbook long division on digit strings. JS's div() works directly on base-1e14 limbs with a divisor-normalization trick. Mine extracts digit strings and does ordinary digit-by-digit long division. This was a correctness-over-performance call, and it has a price tag I'll put on the table later.

Fourteen bugs

The replay harness found them. Here are the ones that taught me something.

The exponent-alignment bug in division (49 / 13). Equal digit lengths, the dividend's leading digits exceeding the divisor's. Caught before it could propagate into dividedBy, modulo, squareRoot, and dividedToIntegerBy — which is the entire argument for building and verifying the primitives first. I built the core representation and the two highest-risk primitives (round() and decimal long division) against real Node ground truth before writing a single higher-level method. That ordering caught three bugs in the core before they could multiply.

toFraction() and a JavaScript aliasing detail. The original's continued-fraction algorithm contains this:

d1 = n0 = new BigNumber(ONE);

d1 and n0 are the same object. Later, mutating n0.c[0] also zeroes d1. In JS, that's just how object references work, and the algorithm quietly depends on it. In Rust, let d1 = n0.clone() gives you two independent values, and the algorithm silently produces the wrong fraction. The fix was explicitly modelling the shared state — but finding it meant reading the original closely enough to notice that an assignment chain was load-bearing.

toFormat()'s digit grouping captured groupSize after a swap instead of before, producing Indian-style grouping where standard was correct, and vice versa. A one-line ordering bug that no amount of staring at my own code would have surfaced. The replay surfaced in seconds.

And then the one that ate the most hours.

round()'s handling of sd < 1 — the case where the rounding position falls before the value's leading digit, in implicit-zero territory that isn't in the stored coefficient at all.

My code treated "the rounding digit" as the value's own leading digit for any sd <= 0. That looks right. It reads right. It is wrong. JS's digit-position formula reduces to "the leading digit" at exactly sd == 0; for sd < 0 it evaluates to rd = 0.

The observable consequence:

"5e-8".toFixed(2)
  ground truth: "0.00"
  my port: "0.01"

Because my version saw the rounding digit as 5 and rounded up, when JS sees 0 and stays at zero.

I did not fix this by guessing. I traced JS's round(x, sd, rm, r) line by line against the specific failing inputs, and the actual insight was structural: JS only consults the sd < 1 branch for the final write-out, never for computing the rounding digit. I had the branch in the right function and at the wrong point in the control flow. The comment I left in src/parse.rs is the one I'd want a future maintainer to read first:

// Compute rd (the rounding digit) and r (whether any nonzero digit exists
// after it) unconditionally, BEFORE any special-casing on `sd < 1`, matching
// JS's structure where the `sd < 1 || !xc[0]` branch is only consulted for the
// final write-out, not for computing rd/r. Getting this order backwards was a
// real bug: treating "sd < 1" as an immediate special case for rd computation
// made e.g. "5e-8".toFixed(2) treat rd as 5 (round up) instead of 0.

There was a sibling bug in the same function, and it's a nice illustration of how representation choices leak. After a value round-trips through base-1e14 limbs, coeff_to_string strips trailing zeros — so digit_count can legitimately end up less than the sd a caller asks for. Dividing at DECIMAL_PLACES=47 produced a 70-digit quotient that round-tripped to 67 stored digits and was then rounded to sd=68. My .take(68) on a 67-character string silently returned 67 characters, so a round-up carry landed on the last real digit instead of an implicit zero at position 68 — quietly dropping the correct final digit. Rust's iterators will happily give you fewer items than you asked for and not say a word about it.

Two of the "divergences" were bugs in my own harness, which is its own lesson. JS's String(-0) is "0" — and bignumber.js's toString() deliberately drops the sign for zero (there's an explicit comment in the source saying so); only valueOf() preserves it. My capture script used String() on every value, destroying the sign of every negative zero before the Rust side ever saw one. Fixing the capture then exposed the mirror-image asymmetry: my replay tool used to_string(), which drops the sign the same way, briefly reintroducing ~181 spurious divergences. A differential harness is a program, and it has bugs, and yours will look exactly like port bugs. Re-run the whole replay after every harness change.

What the fixed test suite couldn't catch

139,907 calls is a lot, but it's a fixed set — every input a group of humans thought to write down. So I built a second harness: a random differential fuzzer. fuzz/generate_inputs.js emits random op,a,b triples biased toward edge cases (zero, negative zero, extreme exponents, 15–40 digit multi-limb values, values sitting exactly on rounding boundaries), which get piped into both fuzz_cli (Rust) and node_driver.js (pinned original), and the outputs get diff'd.

It immediately found two bugs that the entire real test suite had never once exercised:

exponentiatedBy hung forever on a non-integer exponent. Input: pow,056.56912,-339563.81514905096. JS validates unconditionally — if (n.c && !n.isInteger()) throw Error('Exponent not an integer: ' + n) — before entering its exponentiation-by-squaring loop. I had no such check, so the integer-halving loop's termination condition was never satisfied. Not a wrong answer. An infinite loop.
toPrecision/toExponential/toFixed had no argument range validation at all. toprec,561616,0 succeeded silently where JS raises "Argument out of range: 0". JS's intCheck(sd, 1, MAX) calls are unconditional — not gated behind STRICT mode, which is what I'd assumed.

Both fixes changed function signatures to return Result. Both got regression tests.

Then I re-ran everything from a clean build. The replay held at 139,907/139,907, and two fresh fuzz batches — 60,000 and 500,000 cases — produced zero diff lines. Not "zero failures on the operations where I'd found bugs." Zero differing output bytes across every operation the generator emits.

Final state: 139,907/139,907 replayed calls matched exactly. 0 panics, 0 divergences. 560,000 random fuzz cases, 0 diffs. 69 unit tests, each checked against captured Node output rather than hand-written expectations. 0 unsafe blocks.

The performance section, told honestly

Rust is faster. Except where it isn't, and that part matters more.

Operation	Node p50	Rust p50
`plus`	7.5 µs	6.0 µs	comparable
`minus`	5.6 µs	5.4 µs	comparable
`multipliedBy`	5.4 µs	7.0 µs	comparable
`toFixed`	5.8 µs	6.2 µs	comparable
`dividedBy`	20.7 µs	65.9 µs	~2.8x slower
`squareRoot`	49.7 µs	239.7 µs	~4.8x slower
startup	15.58 ms	0.038 ms	~413x faster
peak RSS	64.1 MB	6.6 MB	~9.6x lower

Startup and memory go to Rust by a wide margin, and that number deserves no applause — it's a native binary versus a JIT runtime, it's structural, and quoting it as a win about my code would be dishonest.

The number that is about my code is dividedBy, and it's a loss. My port's division is ~2.8x slower than the JavaScript original, and squareRoot is ~4.8x slower because its Newton-Raphson iteration calls division repeatedly.

That is the direct, predictable cost of choosing schoolbook digit-string long division over the original's normalised base-1e14 algorithm. I made that call deliberately: the digit-string version is dramatically easier to verify against ground truth, and it was verified — that's how the 49/13 exponent-alignment bug got caught before it contaminated four dependent methods. Given a hard deadline and a correctness bar of byte-identical output, I'd rather ship a slow-and-provably-right division than a fast one I couldn't fully verify.

But I'm not going to dress a regression up as a feature. It's in the README, in DECISIONS.md, and in the benchmark methodology alongside its caveats (single run, no warm-up discard, machine not isolated from other loads). A benchmark table that only contains your wins isn't a benchmark; it's marketing.

The decision I'd take back: this one. Not the choice itself — under that deadline it was right — but the sequencing. I should have shipped the digit-string version to establish correctness, then used the now-verified implementation as an oracle to port the original's limb-based algorithm behind it, with the slow version as the differential reference. That's a few hours of work, and it would have closed the only real regression in the port. I ran out of the window before I ran out of plan.

What I'd tell someone starting a port tomorrow

Find the specification before you find the source. For bignumber.js, it was 47,713 lines of tests, not 2,520 lines of implementation. Read the tests first. They encode the promises; the source only encodes one way of keeping them.

Build a differential harness before you build features. Every one of my fourteen bugs came from the harness. Zero came from reading my own code. You cannot review your way to byte-identical output on a numerical library — I was confident and wrong fourteen separate times, and confidence was never the signal.

Verify the primitives before you build on them. Core representation and the two highest-risk primitives went in first, checked against real Node output, before any higher-level method existed. Three bugs died there instead of reproducing into forty methods.

Then fuzz, because your fixed test set is somebody's imagination. 139,907 real calls did not contain a non-integer exponent. Random generation found it in the first 60,000 cases.

Distrust your harness as much as your port. Two of my "divergences" were the observer, not the observed.

Write down what you didn't do. toString(base) — decimal → base-b string conversion — is not ported. The reverse direction is, because the two-argument comparison methods need it. Nothing in the replay exercised the forward direction, so it stays a documented, deliberate scope cut with an unimplemented!() marking the spot. BigNumber.config() as global state, isBigNumber, and toBigInt are also out, each with a reason. A port with three honest gaps is more useful than one with three gaps you have to discover yourself.

Porting is not translation. Translation preserves what the code says. A port has to preserve what the code does — including the parts nobody wrote down, the parts that only exist because Math.pow disagrees with C99, the parts that depend on two variable names pointing at one object, and the parts that only show up on the eight-thousandth call.

The original library was the specification. The tests were in archaeology. The 139,907 calls were the proof.

Port: github.com/PrinceXDev/port-mortem-bignumber-rust — every architectural divergence and all fourteen bugs, with root causes, are in DECISIONS.md.

Original: MikeMcl/bignumber.js (MIT) — a library whose test suite taught me more about numerical correctness than its implementation did, which is the highest compliment I know how to pay a codebase.

ScaleScope: I Built a System That Makes Autoscaling Watchable — Here's What Broke

Prince Panchani — Sun, 09 Aug 2026 16:56:18 +0000

The autoscaler is doing something. You can't see it.

You set a CPU threshold. Load increases. A few minutes later, you refresh a dashboard, and the container count has changed. Somewhere in between, a decision happened:

demand increased → threshold crossed → capacity changed → container started → latency recovered

But you weren't there to watch the chain happen. Instead, you reconstruct it afterwards from logs with different timestamps, dashboards with different sampling rates, and metrics that don't share the same clock.

That gap is why autoscaling still feels like a black box — even when you're the person who configured it.

So I wanted to build something different. Not another mocked autoscaling dashboard. Not a simulated container counter. I wanted real load hitting a real service, Zerops making the real scaling decisions, and the entire causal chain rendered live while it happens.

That's ScaleScope.

🚀 Try It Yourself

Repository: ScaleScope on GitHub
Live Demo: scalescope

What Is ScaleScope?

ScaleScope is an experimental autoscaling observability system built around one idea:

Make the entire scaling decision observable on one timeline.

You pick a load profile — Steady, Ramp, Spike, or Latency-target autopilot — choose a duration, and start the experiment. From there:

A fleet of worker containers sends real HTTP requests to a real target service.
The target burns real CPU per request.
Zerops' own autoscaler decides when to scale — nothing is simulated.
Container count is measured independently, not pulled from a privileged platform API.
A digital twin predicts the container count 15 seconds into the future.
Every experiment is recorded as an append-only event stream.
Runs can be replayed later through the exact same rendering pipeline used live.
Chaos experiments can kill, degrade, or partition the target mid-run.
A scheduler can run unattended experiment suites and compare results across runs.

There are twelve services in the system, and yes — I checked that they all actually do something.

System Architecture

The key architectural decision: Postgres, ClickHouse, and Valkey are projections of the event log — they are not independent sources of truth. Everything traces back to one append-only stream in JetStream.

That's why replay is cheap: replay.js re-emits the same events — preserving their original inter-arrival gaps — into the exact SSE pipeline used by live traffic. The frontend never branches on isReplay. It just renders events. Live and replay speak the same language.

A Live Experiment, Step by Step

Here's what actually happens when you press Start Run, based on the real implementation in apps/gateway/src/orchestrator.js and apps/worker/src/fleet.js.

1. Admission

Before anything starts, the gateway checks two things stored in Valkey: the hourly credit budget and a single-active-run lock. The button is public, and the backend is credit-billed — the budget cannot be an afterthought.

2. The Two-Phase Barrier

This was one of the easiest places to accidentally introduce a race condition. The gateway first opens a subscription for CTRL.READY acknowledgements, then broadcasts CTRL.PREPARE. That ordering is deliberate — a fast worker acknowledging before anyone is listening is exactly the kind of race that might never appear during a demo, then suddenly appear under real load.

Each worker receives PREPARE and performs one throwaway warm-up request, so DNS resolution and connection-pool initialization don't pollute the first real latency bucket.

3. One Shared T0

Once enough workers respond (or the timeout fires), the gateway computes an absolute future timestamp:

const t0 = Date.now() + T0_LEAD_MS;

pub(nc, CTRL.GO, { runId, t0, config, workers });

Every worker derives its per-second buckets from that same timestamp. Five different load-fleet containers can now agree on what "second 7" means without continuously coordinating — instead of worker 1: "7.01s ago", worker 2: "6.94s ago", worker 3: "7.13s ago", they all just tick from the same origin.

4. Load Starts

Each worker maintains its own concurrency pool against the target, using a shared keep-alive HTTP agent (not fetch) for deterministic connection reuse. Concurrency is derived from the selected load profile:

Profile	Behavior
Spike	Jump to full intensity and hold
Ramp	Increase linearly
Step	Move between predefined plateaus
Autopilot	A PID controller adjusts request rate every second to hold a target p95 latency

The autopilot controller is intentionally asymmetric — it backs off quickly, but only increases load as fast as maxRise allows. Ramping quickly is a surprisingly effective way to DoS your own target.

5. The Target Scales

Every target response carries:

X-Instance-Id: 7f83c1a2
X-Instance-Age: 4217

const INSTANCE_ID = crypto.randomUUID().slice(0, 8);
const BOOT_MS = Date.now();

res.set('X-Instance-Id', INSTANCE_ID);
res.set('X-Instance-Age', String(Date.now() - BOOT_MS));

That's the entire container-counting mechanism — no platform API, no privileged credentials, no hidden autoscaler endpoint. The collector tracks distinct instance IDs observed during a rolling 10-second window, and that becomes the live container count.

6. Samples Become Tick Frames

Workers publish per-instance samples to NATS every second. The collector merges them into one TickFrame. For percentiles, the system takes the worst observed p95/p99 across workers rather than pretending percentiles can be averaged; for p50 it uses a request-weighted mean. The resulting frame goes to the gateway, the oracle, and ClickHouse — one second of telemetry becomes one shared representation of system state.

7. The Gateway Broadcasts It

The gateway forwards the same tick frame to connected SSE clients, filtered by runId — a viewer watching a permalink to one experiment never receives events from another active run.

8. The Event Log Becomes the Record

Events — created, armed, started, tick, scaled, chaos, prediction, slo, completed — are appended to JetStream. At finalization, the gateway reads the full event stream and folds it into a summary using one reducer: foldRun(). That same reducer powers the REST API, replay, finalization, the scheduler, and suite success evaluation.

One event stream. One reducer. Multiple projections. That decision ended up being one of the most important architectural choices in the project.

The Engineering Decisions I'm Most Proud Of

Counting containers without a platform API

There's no simple application-layer Zerops endpoint that says "you currently have 4 containers" — and even if there were, depending on a privileged API on the hot path would introduce another dependency. Instead every container identifies itself, and distinct IDs in the rolling window become the count. Simple, observable, and independently measured.

Forcing horizontal scaling

This one broke the demo before it worked. Zerops scales vertically before scaling horizontally — a sensible default for normal workloads. But ScaleScope's entire premise is watch containers appear. If the platform keeps adding CPU to the existing container, the container count never changes.

The fix was one line in the import YAML:

cpuMode: DEDICATED

Dedicated CPU enables the horizontal CPU-trigger behavior the experiment depends on. An earlier version missed this; the system vertically scaled forever, the container count stayed at one, and the demo silently failed at its most important job. A very useful bug to find early.

The digital twin doesn't use machine learning

It learns three parameters: capacity per container, scale-up lag, and scale-down lag. That's it. AutoscalerTwin updates them with exponentially weighted estimates, and capacity updates are intentionally asymmetric:

const rate =
  observed > this.params.capacityPerContainer
    ? alpha
    : alpha * 0.3;

this.params.capacityPerContainer +=
  rate * (observed - this.params.capacityPerContainer);

One overloaded tick shouldn't permanently convince the model that every container is terrible. The model only learns from ticks that are demonstrably not saturated (p95 <= setpoint * 1.1), and it refuses to persist learning from runs shorter than 20 ticks. I watched this guard fire during local testing for runs with 18, 14, and 2 ticks — no special test case, no prompt, it just refused to learn from insufficient data. Exactly what I wanted.

The chaos secret check

The chaos endpoint accepts a secret, compared in a timing-safe way:

const a = crypto.createHash('sha256').update(presented).digest();
const b = crypto.createHash('sha256').update(CHAOS_SECRET).digest();

return crypto.timingSafeEqual(a, b);

timingSafeEqual() requires equal-length buffers — comparing raw strings of different lengths can throw, and careless padding can leak secret-length information. Hashing both inputs first produces fixed 32-byte buffers before comparison. Small detail, worth getting right.

The scheduler doesn't bypass the gateway

The scheduler could publish CTRL.* messages directly to NATS. It intentionally doesn't:

If the scheduler became a second writer to the NATS control subjects, the two paths would eventually drift, bypassing credit limits, active-run locking, admission checks, and barrier logic. So the scheduler behaves like any other client — it calls the public API and polls for progress.

What Actually Broke

Three real bugs survived static checks and careful code reading, and were only discovered when the whole system actually ran.

1. A Postgres type mismatch. One update statement used the same parameter as a bigint in one clause and implicitly as numeric inside to_timestamp() in another. It read fine, passed syntax checks, and the real driver rejected it on the very first POST /api/runs. Nearly invisible in review — humans are good at inferring intent, databases are good at enforcing types.

2. Every log line said [svc]. The telemetry package cached SCALESCOPE_SERVICE at module-load time. ES module imports evaluate before the entry point's own initialization code runs, so by the time each service set its environment variable, the logger had already cached the default. Result: eight services, every log line labelled [svc]. Nothing technically broken, but debugging a distributed system where every service has the same name is painful. Fix: read the environment value at log time instead of caching it at import time.

3. The status panel "fixed itself" into being wrong. The architecture panel did a direct health check, then ~10 seconds later, some services would mysteriously flip to unknown. A heartbeat reconciliation loop was overwriting the direct health result with data from a heartbeat table that nobody was populating for those services:

It was technically reconciling state — just reconciling it with nothing. Fix: exclude those services from that reconciliation path.

None of these three bugs was caught by node --check. All twelve services passed syntax checks early. Once you have event streams, distributed workers, barriers, asynchronous services, databases, caches, and queues, you need to run the actual system — not just the files.

What I Learned Building ScaleScope

1. Static checks tell you surprisingly little about distributed systems. A service can be perfectly valid JavaScript and still be completely wrong when it interacts with seven other services. The bugs weren't syntax bugs — they were system interaction bugs.

2. One event log beats three sources of truth. Making Postgres, ClickHouse, and Valkey projections of one JetStream event stream dramatically simplified replay. If every database independently decided what happened, replay would need a completely different code path. Instead, everything is a projection, and the event stream is the history.

Final Thoughts

ScaleScope started with a simple question: What if you could actually watch an autoscaler think?

The result is a distributed experiment platform for making scaling behaviour observable, replayable, predictable, and deliberately breakable. There's still work left to do, but the core loop works:

Start a run → generate real load → watch Zerops scale → observe the causal chain → replay it afterward.

And honestly, watching that second container appear for the first time was worth every bug that came before it.

Grandma's Kitchen Table — A Photorealistic Pie Scene

Prince Panchani — Tue, 04 Aug 2026 10:03:49 +0000

This is my submission for the Frontend Challenge – Comfort Food Edition: CSS Art.

Grandma's Kitchen Table

Inspiration

Comfort food isn't just about what's on the plate—it's about the memories that come with it.

Growing up, Sunday mornings at my grandmother's house always meant the same scene: a freshly baked lattice pie cooling by the window, tea that had long gone cold because she was busy taking care of everyone else, handwritten recipe cards scattered across the table, and cookies that somehow always appeared beside every cup.

Rather than creating a perfect food photograph, I wanted to recreate the feeling of sitting at that table.

That's why the pie already has a slice missing. There are crumbs where they'd naturally fall, a lace napkin doubling as a coaster, coffee rings on the recipe card, and a handwritten note tucked into the corner that reads:

"Eat more pie! Love, Grandma ♥"

My goal wasn't simply to draw food—it was to capture nostalgia using nothing but CSS.

Demo

🔗 Live Demo: https://princexdev.github.io/css-art-comfort-food/
💻 Source Code: https://github.com/PrinceXDev/css-art-comfort-food

The entire artwork is built using pure CSS.

There are:

❌ No images
❌ No SVG
❌ No Canvas

Everything is created using gradients, masks, pseudo-elements, transforms, shadows, and modern CSS features.

A small amount of JavaScript is used only for subtle interactions, including parallax, drifting steam, and a real-time pocket watch.

Journey

What began as a simple pie illustration gradually evolved into an entire lived-in kitchen table.

Instead of asking, "What food should I draw?" I kept asking, "What would actually be sitting on Grandma's table?"

That question transformed the project into a detailed composition containing nearly twenty handcrafted objects, including:

Lattice pie with a sliced serving
Melting ice cream
Floral teacup
Cookies
Sugar bowl
Jam pot
Milk jug
Pie server
Folded newspaper
Reading glasses
Pocket watch
Brass keys
Wildflowers
Handwritten recipe card
Grandma's note

Every object was built individually using CSS before being composed into a single scene.

Highlights

🥧 A Real Woven Pie Lattice

One of the biggest technical challenges was creating a convincing woven lattice.

A simple clip-path wasn't enough because it couldn't produce alternating visible sections without merging them into a single shape.

Instead, I used CSS mask with hard-stop gradients to selectively hide portions of each strip, allowing the vertical and horizontal pieces to weave naturally over and under one another—just like a real pie.

DEV Community: Prince Panchani

Migrating a 5-year-old React admin app from CRA + Webpack to Vite + SWC — 166 files, 70 days

Why a bundler swap is never a bundler swap

Constraint one: React 16 stays

Chapter 1: type: module and the file-extension domino

Chapter 2: process.env doesn't exist in the browser

Chapter 3: the white screen with no stack trace

Chapter 4: five dependencies that couldn't make the jump

Chapter 5: ReactComponent was never a real thing

Chapter 6: Fast Refresh has opinions about your exports

Chapter 7: the chart.js version that went backwards

Chapter 8: the reviewer who wanted zero

How this was actually validated (the honest version)

What it bought

Takeaways

The 2021 Sentry bug that made every Element Desktop crash unreadable

Project Overview

Bug Fix or Performance Improvement

The main event: Element Desktop's crash reports were minified garbage

The other one: the high-contrast theme had no contrast

Code

Best Use of Sentry

Sentry tools used

Root cause: an opt-out that silently freezes in time

The fix

The two-character detail that would have shipped a fake fix

So I tested the output, not the config

Verified against a real Sentry project

Answering the question that had been open since 2021

My Improvements

The accessibility bug: a token that means the opposite thing in a different theme

Widening the test caught a second, unreported bug

Coda: the fix that was correct and still got rejected

Takeaways

Credits

From a 15-Second Walk to a Digital Memory: Building a Canine Cognitive Twin

What I Built

Demo

🎥 Live Demo

💻 Source Code

Demo Status

Implemented Pipeline

Synthetic Data Disclosure

Architecture

Why I Made These Architecture Decisions

Browser Upload Instead of a Mobile App

Oracle Relay Instead of Direct Snowflake Signing

Separate Runtime Implementations

Fallback Instead of Silent Failure

Prize Technology

Code

PrinceXDev / dog-day-edition

Canine Cognitive Twin

What is live vs. what is synthetic

Live — clicked during the demo, nothing faked

What's Next

Prize Categories

Final Note

The 2 A.M. Fridge: A Landing Page With Exactly One Light Source

🍕 What I Built

🚀 Demo

🧑‍💻 Journey

139,907 Calls Later: What It Actually Takes to Port a Numerical Library from JavaScript to Rust

139,907 Calls Later: What It Actually Takes to Port a Numerical Library from JavaScript to Rust

The project I chose

What bignumber.js is for

The archaeology: the source code was the smaller half of the artefact

A port is not a translation

What the number actually is

Fourteen bugs

What the fixed test suite couldn't catch

The performance section, told honestly

What I'd tell someone starting a port tomorrow

ScaleScope: I Built a System That Makes Autoscaling Watchable — Here's What Broke

🚀 Try It Yourself

What Is ScaleScope?

System Architecture

A Live Experiment, Step by Step

1. Admission

2. The Two-Phase Barrier

Chapter 1: `type: module` and the file-extension domino

Chapter 2: `process.env` doesn't exist in the browser

Chapter 5: `ReactComponent` was never a real thing