/ tech-stacks / Best Tech Stack for a VS Code Extension as a Solo Developer
tech-stacks 11 min read

Best Tech Stack for a VS Code Extension as a Solo Developer

The best tech stack for building a VS Code extension as a solo developer - frameworks, databases, hosting, and tools.

Hero image for Best Tech Stack for a VS Code Extension as a Solo Developer

Best Tech Stack for a VS Code Extension as a Solo Developer

VS Code extensions are an underrated solo developer play. The marketplace has over 40,000 extensions and millions of active users. If you can solve a real developer pain point, you've got built-in distribution through the VS Code marketplace with zero marketing budget. The key is picking a tech stack that keeps development fast and testing painless.

Here's the exact stack I'd recommend for building a VS Code extension in 2026.

Layer Pick Current Version
Language TypeScript (required, essentially) 6.0.3
Scaffolder generator-code (yo code) 1.11.18
UI Webview (React) for complex UI, native API for simple n/a
Bundler esbuild 0.28.0
Backend (if needed) Hono on Cloudflare Workers Hono 4.12.23, Wrangler 4.95.0
Database (if needed) Cloudflare D1 or Turso n/a
Testing Vitest + @vscode/test-electron Vitest 4.1.7, test-electron 2.5.2
Packaging @vscode/vsce 3.9.1

Versions in this guide were pulled from the npm registry on 2026-05-30. Run npm view <package> version before you pin anything, since these move fast.

The Core: TypeScript + VS Code Extension API

There's no real choice here. While VS Code extensions technically support JavaScript, TypeScript is the only practical option. The VS Code Extension API is entirely typed, and trying to build without those types is like coding blindfolded. Every example in the docs uses TypeScript. Every popular extension uses TypeScript. Use TypeScript.

The VS Code Extension API itself is massive and well-documented. You get access to the editor, file system, terminal, source control, debug adapter, language server protocol, and more. The yo code generator scaffolds a working extension in under a minute.

Start with the official generator:

npx --package yo --package generator-code -- yo code

Pick TypeScript, and you'll have a working "Hello World" extension with proper project structure, launch configurations, and a test setup.

Frontend / UI: It Depends on Complexity

VS Code extensions have two UI approaches, and picking the right one matters:

Native API (for most extensions): Use VS Code's built-in UI components: TreeViews, QuickPicks, StatusBar items, InputBoxes, and Notifications. These are fast, consistent with the editor's look, and require zero frontend framework knowledge. If your extension is a linter, formatter, snippet collection, or command palette tool, native API is all you need.

Webview Panels (for rich UI): If you're building something visual like a dashboard, diagram editor, or settings panel, you'll need Webview panels. These are essentially iframes that can render any HTML/CSS/JS. Use React with a lightweight setup.

One important update for 2026: the old @vscode/webview-ui-toolkit package that used to be the go-to for VS Code-styled webview components is now deprecated. Microsoft archived the NPM package and main repository on January 6, 2025, because its core FAST Foundation dependency was itself being deprecated and a full rewrite was never resourced. Don't start a new extension on it. Instead, style your React components yourself against the VS Code theme by reading the CSS variables VS Code injects into the webview (for example var(--vscode-button-background) and var(--vscode-editor-foreground)), or pull in a community-maintained component set. The CSS-variable route is zero-dependency and tracks the user's active theme automatically.

One thing to watch out for: Webviews can't directly access the VS Code API. Communication happens through message passing (postMessage / onDidReceiveMessage), so plan your data flow accordingly.

Bundler: esbuild

The official VS Code bundling guide presents esbuild and webpack as the two main options, describing esbuild as "a fast JavaScript bundler that's simple to configure." For a solo developer that simplicity is the whole pitch. The configuration is minimal and it produces small bundles that make your extension load quickly. esbuild is also widely battle-tested, with roughly 39,900 GitHub stars and around 228 million npm downloads in the last week as of 2026-05-30.

One thing the docs call out: esbuild "simply strips off all type declarations without doing any type checks," so it does not validate your TypeScript on its own. Run tsc --noEmit separately (or as a pretest step) to catch type errors that esbuild will happily ignore.

A slow-loading extension gets bad reviews fast. Users notice when your extension adds 500ms to their startup time. esbuild keeps your bundle tight and your activation time low.

The yo code generator can scaffold esbuild configuration for you. Stick with it.

Backend: Cloudflare Workers (If Needed)

Many VS Code extensions are purely local and don't need a backend. But if yours requires authentication, a license server, syncing settings across machines, or AI/API features, you need something lightweight.

Cloudflare Workers with Hono is ideal for solo developers building extension backends. Hono is the routing layer here, a small web framework with roughly 30,700 GitHub stars and around 38.5 million npm downloads in the last week as of 2026-05-30, so it is well past the maintenance-risk stage.

  1. Near-zero cold starts - Your API responds fast, which matters when users trigger it from their editor.
  2. Free tier - The Workers free plan includes 100,000 requests per day and 10 ms of CPU time per invocation, which is more than enough for a growing extension. The paid plan starts at a $5/month minimum and includes 10 million requests per month.
  3. Global edge deployment - Low latency for developers worldwide.
  4. Simple deployment - wrangler deploy (Wrangler 4.95.0 as of 2026-05-30) and you're done.

For extensions that need to store user data or license keys, pair Workers with Cloudflare D1 (SQLite at the edge) or Turso (distributed SQLite). Both have generous free tiers. The D1 free tier includes 5 million rows read per day, 100,000 rows written per day, and 5 GB total storage. Turso's free plan includes 5 GB storage, up to 100 databases, and 500 million rows read per month, with the paid Developer tier starting at $4.99/month. Verify both against current pricing pages before you commit, since free-tier limits get revised.

Database: Keep It Local First

Before reaching for a remote database, remember that VS Code has built-in storage APIs:

  • context.globalState - Global key-value storage VS Code restores on each activation. To make selected keys ride along with Settings Sync across machines, call context.globalState.setKeysForSync([...]).
  • context.workspaceState - Per-workspace key-value storage VS Code restores when the same workspace reopens.
  • context.secrets - Encrypted storage for API keys and tokens.

For most extensions, these built-in options are sufficient. Only add a remote database when you genuinely need server-side data persistence, like a license system or cross-device sync beyond what Settings Sync provides.

Testing: Vitest + VS Code Test Runner

Testing VS Code extensions has gotten much better. Use Vitest (4.1.7 as of 2026-05-30, roughly 16,600 GitHub stars and around 59 million npm downloads in the last week) for unit testing your business logic, meaning anything that doesn't touch the VS Code API directly. It's fast and has great TypeScript support.

For integration tests that need the actual VS Code environment, use @vscode/test-electron (2.5.2 as of 2026-05-30). It launches a real VS Code instance, installs your extension, and runs your test suite. It's slower but essential for testing commands, UI interactions, and API integration.

Nice-to-Haves

  • @vscode/vsce (3.9.1 as of 2026-05-30) - Official CLI for packaging and publishing to the marketplace
  • Sentry - Error tracking, because VS Code extensions can silently fail without you knowing. The free Developer plan covers 5,000 errors per month and one user, with the Team plan at $26/month billed annually.
  • Gumroad - If you want to sell a premium version (check current fee structure before launch)
  • GitHub Actions - Automate publishing on git tag push

Monthly Cost Breakdown

Service Cost Free-tier ceiling (as of 2026-05-30)
VS Code Marketplace $0 Free to publish
Cloudflare Workers (if needed) $0 100,000 requests/day, 10 ms CPU/invocation
Cloudflare D1 (if needed) $0 5M rows read/day, 100K rows written/day, 5 GB
Turso (alternative DB) $0 5 GB, 100 databases, 500M rows read/month
Sentry (free tier) $0 5,000 errors/month, 1 user
Total $0/month

That's right. You can build, host, and distribute a VS Code extension for absolutely nothing within these free-tier limits. The marketplace listing is free, Cloudflare's free tier covers most extensions, and your users install directly from VS Code. The first paid steps, if you ever cross those ceilings, are modest: Cloudflare Workers at a $5/month minimum, Turso Developer at $4.99/month, and Sentry Team at $26/month billed annually.

Common Errors and Fixes

A few snags that trip up almost everyone on their first extension.

esbuild ships a bundle that crashes at runtime with type errors you never saw. esbuild strips TypeScript types without type-checking, per the official bundling guide, so a real type bug sails straight through the build. Add a separate tsc --noEmit step (wire it into your pretest or vscode:prepublish script) so the compiler still catches what the bundler ignores.

You built your webview on @vscode/webview-ui-toolkit and npm warns it is deprecated. That package was archived on January 6, 2025 after its FAST Foundation dependency was deprecated. There is no drop-in official replacement. Style your React components against the VS Code theme CSS variables (for example var(--vscode-button-background)), which is zero-dependency and theme-aware, or move to a community-maintained component set.

Your webview cannot call the VS Code API directly. Webviews run in an isolated iframe context. Use the message channel: acquireVsCodeApi().postMessage(...) from the webview side and panel.webview.onDidReceiveMessage(...) on the extension side. Trying to import vscode inside the webview bundle will fail.

vsce publish rejects your package over a missing publisher or repository field. @vscode/vsce validates package.json before upload. Make sure publisher, repository, and a real README.md are present, and that you are authenticated with a Personal Access Token from your Azure DevOps publisher account.

Keys you saved in globalState do not follow the user to a second machine. globalState only syncs the keys you explicitly opt in. Call context.globalState.setKeysForSync([...]) with the keys you want carried across machines via Settings Sync.

Cloudflare Workers returns a 429 or stops responding under light traffic. The free plan caps at 100,000 requests per day and 10 ms CPU per invocation. If you are hitting that, either trim per-call CPU work or move to the Workers Paid plan at the $5/month minimum.

Sources

Conclusion

The ideal stack for a solo developer building a VS Code extension: TypeScript with esbuild for the extension itself, native VS Code UI components first (Webview + React only when needed), and Cloudflare Workers if you need a backend. Total monthly cost: zero dollars.

VS Code extensions are one of the few software products where distribution is truly free, infrastructure can be free, and a single developer can compete with teams. Focus your energy on solving a real developer problem, keep the technical complexity low, and let the marketplace do the distribution work for you.

Built by Kevin

Like this? You'll like what I'm building too.

Two ways to support and get more of this work.

Desktop App

HEARTH

A privacy-first Life OS for your desktop. Journal, tasks, and notes that stay on your machine. Coming soon, direct download from this site.

Read more
Digital Products

MY TOOLKITS

Receipts-first toolkits for shipping after hours, building Claude agents, publishing on Amazon, and more. The exact methods I used, not theory.

Browse on Whop

Need This Built?

Kevin builds products solo, from first version to live. If you want something like this made, work with him.