How to Publish a VS Code Extension as a Side Project

To publish a VS Code extension as a side project, pick one small command that saves you time every day, scaffold it with the official generator, keep activation lazy, package it with vsce, and publish it to both the Visual Studio Marketplace and Open VSX. The Marketplace reaches people using VS Code itself. Open VSX reaches people using editors built on the same code, such as VSCodium and Cursor. Then treat the README as your store page and let one honest post do the rest.

This is for developers with a day job who keep tripping over the same small editor annoyance and want to turn the fix into something other people install. The steps follow the official VS Code, vsce and Open VSX docs, checked on 3 November 2026. Publishing rules are changing right now, so read the dates. The worked example near the end is made up.

Is a VS Code extension the right shape for your side project?

An extension is a good fit when the problem lives inside the editor and happens many times a day. It is a poor fit when the work could happen anywhere. Run a quick fit check:

• The annoyance happens while you are editing. Renaming, copying, formatting, cleaning up a selection. If it happens in a terminal, a small CLI may be simpler.

• Your users are developers. People who never open an editor will never find it, however good the listing is.

• One command could carry it. If the idea needs a dashboard, accounts and a server, it is a web tool that happens to have an extension, not an extension.

• You use it yourself every day. That keeps you honest about speed and bugs, and makes it useful even if nobody else installs it.

If your idea lives in the browser instead, the SideHunt guide to shipping a browser extension as a side project covers that path. Everything below is about the editor.

How do you pick the one job your extension does?

Write the job as a command name before you write any code: a verb and an object, like "Sort selected lines by length" or "Copy file path with line number". If you cannot name it in five words, it is two extensions.

Then search the Visual Studio Marketplace for the job, not your name. Finding something close is fine if yours is faster or simpler. It is a warning if the top result already does exactly your job with good reviews.

Check the name early. The Publishing Extensions guide says the Marketplace requires the extension name to be unique, and the same rule applies to the display name. It also says that once an extension is removed, its name is permanently reserved and cannot be reused, even by you. Pick a name you are happy to keep.

How do you scaffold a VS Code extension?

Use the official generator. The Your First Extension guide runs it without a global install with npx --package yo --package generator-code -- yo code. Choose New Extension (TypeScript), let it initialise git, then open the main source file and press F5. That compiles the extension and opens a second window called the Extension Development Host, where you can run your command from the Command Palette.

Most of what users and the stores see comes from the manifest, your package.json. The extension manifest reference lists every field. These are the ones worth getting right on day one:

How do you keep a VS Code extension fast and quiet?

People uninstall extensions that slow their editor or interrupt them. Three habits keep yours light.

Activate late. The activation events reference says that since VS Code 1.74, commands your extension contributes no longer need a matching activation entry: running the command wakes the extension. Avoid the * event, which activates on every start-up; the docs ask you to use it only when nothing else works. If you truly need to run early, onStartupFinished waits until start-up is done.

Bundle and trim. The bundling guide explains that loading 100 small files is much slower than loading one large file, and walks through setting up esbuild. Add a .vscodeignore file so source files, tests and configs stay out of the package. Packages listed as devDependencies are left out automatically.

Stay out of the way. Put options under contributes.configuration so they appear in the Settings editor, and include one setting that turns the main behaviour off without uninstalling. Microsoft's notification guidelines say to notify only when necessary, never for promotion, and not to ask for feedback on first install. A quiet extension gets kept.

How much testing does an extension need before the first release?

Less than you fear, more than none. Run the command by hand on a real project of yours, then add one smoke test that opens a file, runs the command and checks the result. The testing extensions guide sets this up with @vscode/test-cli and @vscode/test-electron, which run your tests inside a real VS Code instance. For how far to go after that, see how much testing a side project actually needs.

How do you publish to the Visual Studio Marketplace?

Publishing is a short sequence, with one important change this year. According to the Publishing Extensions guide, global Personal Access Tokens in Azure DevOps are retired on 1 December 2026, and Microsoft recommends Trusted Publishing from GitHub Actions instead of storing a token. Plan for that from the start.

1. Create a publisher on the Visual Studio Marketplace publisher management page with a Microsoft account. The guide says the publisher ID appears in your extension URLs and cannot be changed once created.

2. Install vsce, the official packaging tool. Its vsce repository lists Node 22 or newer as a requirement.

3. Package first. vsce package builds a VSIX file you can install locally with Install from VSIX in the Extensions view. Install it in your own editor and use it for a day.

4. Publish. From CI, Trusted Publishing uses vsce publish --oidc. You can also upload the VSIX by hand on the publisher management page, which the guide lists as the manual route.

5. Bump versions with the tool. vsce publish minor raises the version and publishes it, and inside a git repo it also creates a version commit and tag.

Two more details. Pre-release versions are published with --pre-release, and the guide recommends even minor numbers for releases and odd ones for pre-releases, because VS Code always updates to the highest version. And the Marketplace runs checks on every upload: the extension runtime security page says each new extension and update is malware-scanned and not public until the scan is clear, and that publishing is blocked if secrets such as API keys are found in the package.

Why should you publish to Open VSX too?

Because many developers cannot install from the Microsoft Marketplace at all. The Cursor extensions docs say Cursor uses the Open VSX registry for third-party extensions. The VSCodium extensions docs say Open VSX is its default gallery and that Microsoft prohibits other products from using its marketplace. If you skip Open VSX, those users either cannot find you or find someone else's copy.

The Open VSX publishing guide takes one evening:

1. Create an Eclipse account and fill in the GitHub Username field with the same GitHub account you will use on Open VSX.

2. Log in to Open VSX with GitHub, connect your Eclipse account in Settings, and sign the Publisher Agreement.

3. Generate an access token under Settings, Access Tokens. Store it somewhere safe; it is shown only once.

4. Create your namespace, which must match the publisher field in your manifest: npx ovsx create-namespace with your publisher name and token.

5. Publish with npx ovsx publish and your token, or point it at the VSIX you already built.

Open VSX can scan uploads too. The guide lists secret detection, a blocklist of known-bad files, and a namespace similarity check that rejects names too close to existing ones. Creating a namespace does not make you its verified owner; that is a separate claim if you want the badge.

How do you automate releases to both registries?

Set it up once and every release after that is a git tag. The continuous integration guide covers running tests in CI; the publishing side looks like this:

• Trigger on tags. Run the workflow when you push a tag that starts with v, after the tests pass.

• Marketplace with Trusted Publishing. Create a Trusted Publishing policy for your repository and workflow file in the publisher management page, give the job id-token: write permission, and run npx @vscode/vsce publish --oidc. No Marketplace token is stored in GitHub. The guide notes that for a private repository you must run the workflow within 48 hours of creating the policy.

• Open VSX with a token or without one. The ovsx tool reads a token from an OVSX_PAT environment variable, so a repository secret with that name works. The ovsx CLI readme also documents trusted publishing for Open VSX, which removes that secret too.

• Ship the same file twice. Package once, then publish that exact VSIX to both registries, so users on either one get identical code.

What makes a Marketplace listing people install?

Your README.md becomes your Marketplace page, so write it for someone deciding in ten seconds. Open with one line that says what the command does, then a short GIF of it working on real code, then a settings table, then a link to your CHANGELOG.md. The Publishing Extensions guide also suggests a LICENSE file and a SUPPORT.md in the root, and it sets hard rules for images: README and changelog images must use https URLs, and SVG images are refused unless they come from approved badge services.

How do you earn trust as an unknown publisher?

Nobody knows your name yet, so show your work. Link the source repository from the manifest. Collect no telemetry in version one; if you add it later, the telemetry guide for extension authors says you must respect isTelemetryEnabled, collect as little as possible and never collect personal data. If your extension sends anything off the machine, say so plainly, and see writing a privacy policy for your side project.

The verified publisher badge comes later. The Publishing Extensions guide says you need an extension on the Marketplace for at least six months and a domain registered for at least six months before you can apply, and the review then takes up to five business days.

How do you find your first users without begging for reviews?

Go where people already describe the annoyance. Search issue trackers, forums and Q&A threads for the exact problem your command solves, and answer properly, with the extension as one option. Then link it from your own projects' READMEs, where developers who already trust your code will see it. Skip rating popups; the notification guidelines rule out asking for feedback on first install.

How do you keep support light with a day job?

• Issue templates that ask for the VS Code version, the extension version and steps to reproduce.

• Saved replies for the questions you get every week.

• A monthly check that your one smoke test still passes on the latest VS Code; raise the engines version only when you need a newer API.

• Pre-releases for risky changes, so opted-in users find bugs first.

• Unpublish, do not remove, if you stop. The guide says removal is irreversible and deletes your statistics, while unpublishing keeps them.

On money, keep expectations honest. The manifest has a sponsor field that shows a sponsor link on your listing, the simplest way for grateful users to support you. Most small extensions pay off through reputation and the projects they point to.

Which traps catch first-time extension authors?

• Activating on * "just in case" and slowing every editor start.

• Shipping the whole project folder because nobody wrote a .vscodeignore.

• Publishing only to the Microsoft Marketplace and missing Cursor and VSCodium users.

• Building release automation on a Personal Access Token that stops working on 1 December 2026.

• Leaving an API key in the package and having the upload blocked.

• Adding features before the first one has users.

A made-up example: Ines and Marrowtab

This example is invented, including the numbers. Ines is a backend developer who leaves TODO comments everywhere and loses them. She builds Marrowtab, an extension with one command: "Marrowtab: Collect TODOs", which gathers every TODO in the open file into a Markdown checklist in a new tab.

She scaffolds it on Saturday, declares the command and one setting for the keyword it searches for, adds a smoke test and an ignore file, and gets the VSIX under 30 KB. On Sunday she creates a Marketplace publisher and an Open VSX namespace with the same ID, sets up Trusted Publishing, and tags v0.2.0.

Her README opens with one line and a six-second GIF. Two weeks later she answers a forum thread asking how to list all TODOs in a file and links Marrowtab from the README of her popular CLI. After a month she has 140 installs on the Marketplace, 60 on Open VSX, three issues and one pull request adding FIXME support. She tags v0.4.0 and goes back to her day job.

A one-weekend plan

Timings are suggestions. If Sunday runs out, publish by hand and automate later.

FAQ

Is it free to publish a VS Code extension?

Neither the Publishing Extensions guide nor the Open VSX publishing guide mentions a fee. You need a Microsoft account for the Marketplace publisher and an Eclipse account plus GitHub login for Open VSX.

Does a VS Code extension work in Cursor?

Usually, if it is on Open VSX. Cursor's docs say it installs third-party extensions from Open VSX and warn that the same ID can point to different code there, so publish there yourself under the same ID.

How long does Marketplace review take?

The docs give no fixed time for a normal upload. They say each new extension and update is malware-scanned and stays private until the scan is clear. The only stated timeline is for verified publisher requests: up to five business days.

Do I need Open VSX too?

If you want people on VSCodium, Cursor and other editors that use Open VSX, yes. It costs one evening of setup, and after that the same release workflow publishes to both.

Ship the one command, then listen

A VS Code extension side project works best as one fast command you use daily, published to the Visual Studio Marketplace and Open VSX from one tagged release, with a README that shows it working. Fix what first users report before adding anything new. And when your project is ready for people who browse side projects on purpose, list it on SideHunt.