Bernhard the Builder
AboutAppsBlogNews

Publishing IDE Extensions: The Practical Guide

How to get your extension on VS Code, Cursor, and Antigravity marketplaces

Publishing IDE Extensions: The Practical Guide
Guide
Bernhard Rieder
2025-12-27
4 MIN READ
Download Resources
AI Directive

Publishing IDE Extensions: From Build to Marketplace

You built an extension. Now you want it out there. The docs are scattered. Microsoft says one thing, Open VSX another. I spent hours figuring out the actual path to publishing IDE extensions - build a .vsix, upload to two platforms, done. No bullshit. Here's what works.
>
Build a .vsix file, upload it to two platforms, and you're done. That's publishing IDE extensions in practice.
VS CodeOpen VSXCursor
What This Guide Covers //
Publishing IDE extensions to Microsoft Marketplace (VS Code) and Open VSX (Cursor, Antigravity). Same .vsix file for both. One build, two uploads.

The Two Marketplaces

Here's what you need to know:
  1. Microsoft Marketplace - For Visual Studio Code
  2. Open VSX - For Cursor IDE and Antigravity IDE (they use the same platform)
Important: Cursor and Antigravity both use Open VSX. Same .vsix file, same upload process. No difference. One upload covers both IDEs.
INSTALL FOR VS CODE
INSTALL FOR CURSOR & ANTIGRAVITY

Step 1: Build Your .vsix File

This is the packaged version of your extension. Everything gets compiled into one file.

The Process

  1. Compile your extension - Build your TypeScript/JavaScript code
  2. Package it - Use vsce to create the .vsix file
  3. Test it locally - Install the .vsix file before publishing
Don't Skip Local Testing //
Testing your .vsix file locally is non-negotiable. Install it locally, test all features, make sure everything works. I've seen extensions ship with broken icons because someone skipped this step.
Important: Testing your .vsix file locally is super important. I am writing a dedicated guide for this process, but for now: install it locally, test all features, make sure everything works. Don't skip this step.

Versioning is Critical

Keep the same filename when you update versions. The marketplaces handle versioning internally based on your package.json.
Important: When you build a new version, tell your AI agent (or yourself) what version number to output. Update it in package.json first, then package.
Example:
  • First version: my-extension-1.0.0.vsix
  • Update version in package.json to 1.0.1
  • Build: my-extension-1.0.1.vsix (or keep same name, marketplace reads version from package.json)

Step 2: Configure Your Extension

Your package.json is where the magic happens. Key fields you need:
  • publisher - Your unique publisher ID (create account first)
  • version - Semantic versioning (1.0.0, 1.0.1, etc.)
  • name - Extension identifier (lowercase, no spaces)
  • displayName - What users see
  • description - Brief description (used in search)
  • categories - Helps users find your extension
  • keywords - Important for search (array of strings)
  • engines.vscode - Minimum VS Code version required
Pro tip: Keep config snippets short. Don't paste entire files. Show the important parts.

Step 3: The Most Important Part - README.md

This is critical. Your README.md file is what gets exposed in the marketplace. It's how users find you. It's how search works. It's everything.

Why It Matters

  • Search rankings - Marketplaces index README content
  • User decisions - Users read README to decide if they want your extension
  • Discoverability - Keywords in README help users find you
  • Professionalism - A good README builds trust

The Critical Detail

Your README.md must be included in the packaged .vsix file. That's how it gets to the marketplace. Make sure it's in your extension directory before packaging.

What Makes a Great README

  • Immediate description - Tell users exactly what your extension does in the first paragraph
  • Features - Clear list of what it does
  • Installation - How to install it
  • See It In Action - Screenshots, GIFs, videos
  • How to Use - Clear usage instructions
  • Keywords - Strategically placed throughout (think like your users)
>
Your README is your extension's sales page. Make it excellent. The marketplace is a search engine
  • your README is what gets indexed.
There's so much more to cover about README.md that a dedicated guide is in the works. But for now, know this: Your README is your extension's sales page. Make it excellent.

Step 4: Create Your Accounts

You need accounts on both platforms. Do this before publishing.

Microsoft Marketplace

  1. Go to marketplace.visualstudio.com/manage
  2. Sign in with Microsoft account
  3. Create publisher profile
  4. Get your publisher ID
Note: You do NOT need Azure DevOps. Just a Microsoft account. That's it.

Open VSX

  1. Go to open-vsx.org
  2. Sign in with GitHub (or create account)
  3. Create namespace (your publisher ID)
  4. You're ready to publish

Step 5: Publish to Microsoft Marketplace

Use the web platform. It's straightforward.
  1. Login to marketplace.visualstudio.com/manage
  2. Create new extension or select existing one
  3. Upload your .vsix file
  4. Fill in metadata - Description, screenshots, etc.
  5. Submit for review
Review process:
  • Automated review: 5-10 minutes usually
  • First-time publishers: May need manual review (24-48 hours)
  • Check your email for any issues

Step 6: Publish to Open VSX

Same process, different platform.
  1. Login to open-vsx.org
  2. Go to your namespace
  3. Create new extension or update existing
  4. Upload your .vsix file
  5. Fill in metadata
  6. Publish
That's it. Your extension is now available for:
  • Cursor IDE users
  • Antigravity IDE users
One upload, two IDEs. Smooth like a tender loving schmuse-katze. 🐱
Mission Accomplished //
Build your .vsix. Upload to two platforms. Make sure your README.md is excellent. That's publishing IDE extensions. The hard part is building a great extension. The publishing part? Just logistics.

Quick Checklist

Before you publish:
  • [ ] Extension compiled and tested
  • [ ] .vsix file created and tested locally (see dedicated guide)
  • [ ] package.json configured with publisher ID
  • [ ] Version number updated
  • [ ] README.md included in extension directory
  • [ ] README.md is professional and keyword-rich
  • [ ] Accounts created on both marketplaces
  • [ ] Screenshots ready (at least 3-5)
  • [ ] Extension tested in target IDEs

Common Mistakes

Don't do this:
  • ❌ Forget to include README.md in your extension directory
  • ❌ Skip testing the .vsix file locally
  • ❌ Use generic descriptions
  • ❌ Forget to update version numbers
  • ❌ Publish without proper README.md
Do this:
  • ✅ Test thoroughly before publishing
  • ✅ Write an excellent README.md
  • ✅ Use clear, descriptive names
  • ✅ Include visual examples (screenshots/GIFs)
  • ✅ Keep extensions updated

That's It

Build your .vsix file. Upload to two platforms. Make sure your README.md is excellent. Mission accomplished. 🚀
The process is straightforward once you know the steps. The hard part is building a great extension. The publishing part? That's just logistics.
Get your extension out there. Share your work. Help other developers.
Questions? Issues? Build it, test it, publish it. That's how you learn.

Article Stats

2Marketplaces
ActiveStatus

Latest Blog Posts

Manifesto2026-05-02

The Rise of the Agentic Internet

The era of building website content is dead. The digital world just hasn't seen the body yet. I am moving to Full Agentic AI — and the implications will dismantle the current server-based software industry.

2026-02-12

LM Studio vs. Ollama

LM Studio runs Llama 4 Scout on local GPUs - but even 96GB VRAM has limits. Context length matters. Kilo Code bridges your IDE to local models. Here is what I learned.

Best Practices2026-02-08

Why You Must Run ESLint Before You Touch the "Cloud"

Running ESLint locally isn't optional - it's your first defense against broken Vercel deployments. I learned this the hard way when my code pushed to Git, triggered Vercel, and failed after 5 minutes of waiting. The fix? A 0.5-second local ESLint check that catches errors before they reach production. Here's why ESLint prevents deployment failures, code rot, and invisible performance bugs.

Achievement2026-02-08

Building a Neural Link Architecture: Zero Link Rot with AI-Powered Semantic Linking

I got absolutely fed up with broken internal links and manual link maintenance. The problem? Hardcoded links rot when slugs change. The solution? A neural link architecture that uses vector embeddings, hybrid ranking algorithms, and AI to automatically inject semantically relevant links at render-time. This system eliminates link rot, scales to thousands of articles, and ensures every link is contextually relevant. Here's how I built a semantic linker that treats websites as living knowledge graphs for AI citation systems.

A
B
C

This article is part of a Semantic Cluster. All links are managed by the Digital Architect AI.