The Developer's Journey: Bringing Ginexys to VS Code

_Build in public — Part 4 of the Ginexys series_

I shipped the web tools. TAFNE for tables, PDF Processor for document extraction, Schema Editor for circuit and software diagrams. They worked. People used them. And then someone asked the question I'd been half-ignoring:

"Can I use this without opening a browser tab?"

Fair. Developers live in their editor. The context switch to a browser tab to format a CSV or trace a circuit diagram is friction — small friction, but friction compounds. If your tool doesn't meet people where they already are, you're asking them to build a new habit. That's a hard sell.

So I started thinking about a VS Code extension.

The first trap: "just wrap it in a webview"

My first instinct was the obvious one. Take the HTML, shove it in a webview, call it done. But VS Code webviews have strict CSP rules. They don't run on localhost. Relative paths like src="src/js/tifany.js" don't resolve. Scripts loaded from CDN need explicit CSP entries. The window.parent !== window check that my bridge.js used to detect embedding? Always false in a webview — no parent frame exists.

I spent a morning debugging a blank white panel before I understood what was actually happening.

The bridge that let my tools talk to the OS shell (bridge.js) was silently installing no-ops the whole time. Every CwsBridge.send() call was a void function. The tool loaded. Nothing worked.

The fix wasn't to patch bridge.js. It was to replace it entirely with a new vsc-bridge.js that uses acquireVsCodeApi() — the VS Code webview API — instead of window.parent. Same surface, different plumbing. Once that clicked, everything else followed.

The architecture that actually worked

Extension Pack + satellites. One ginexys.core extension that handles auth, routing, and shared utilities. Three satellite extensions — ginexys.tafne, ginexys.pdf, ginexys.schema — each a Custom Editor for their file types. A ginexys Extension Pack that installs all four together.

The key insight: the tool SPAs load directly as the webview document. No iframe. No separate server. The HTML rewriter runs at open time, converting every /assets/ and src/js/ path to a vscode-webview:// URI. The VS Code extension host handles IPC where the OS kernel used to.

It's the same architecture. Just a different shell.

The problem I didn't see coming: 10,000 sheets

I added live sync. VS Code text editor on the left, TAFNE table renderer on the right. Type CSV, table updates. Clean.

What I didn't notice until I stress-tested it: every keystroke called parseInput(). And parseInput() always calls addSheet(). Which creates a new tab. After a paragraph of typing you had 200 sheet tabs. After a few minutes, thousands.

The fix had two parts. First: 300ms debounce in the extension host — don't fire on every keystroke, wait for a pause. Second: a new ginexysUpdateSheets() function in TAFNE that patches existing sheet objects in-place — updates rawHtml, calls generateTabs() directly — without ever touching addSheet(). The sheet count stays stable.

But then I thought: what if the document isn't just CSV? What if someone is writing notes in Markdown and has CSV data and JSON data in fenced code blocks?

So now TAFNE understands fenced blocks:

<pre><code># My analysis notes

Some observations...</code></pre>csv product,qty,price Widget A,10,25.00 Widget B,5,49.99 <pre><code> Reference data:</code></pre>json [{"sku":"WA-001","stock":150}] <pre><code></code></pre>

Two fenced blocks → two sheets. Live-updating as you type. Non-table fences ( `javascript ) are skipped. It turned a CSV formatter into something closer to a data notebook — not because I planned it, but because the architecture made it obvious.

What's next

The extension works. TAFNE opens CSV files, renders tables, syncs with the VS Code editor. The mode commands are in place — Command Palette → "Open Node Editor" takes you straight to the right tab.

What's missing is the backend. Auth (Supabase), billing (Lemon Squeezy), rate limiting (Upstash Redis). The architecture is designed and documented. Implementation is next.

The paid tier unlocks two AI-powered MCP tools: AI-powered PDF extraction via Docling, and GINEX Agent for schema analysis. The free tier — table formatting, geometry-pipeline PDF extraction, schema reading — stays free, offline, and works without an account.

That's the SiaS model. The AI capability lives on top of a fully functional offline tool. You get value before you pay. The AI is an accelerant, not a gate.

_Follow the build at ginexys.com/blog or on X @GINEXYS._