vscode extension support

[howarddo2208]

Check for existing issues

• Completed

Describe the feature

Hello Zed team,

As a user of Zed, I have been impressed with its speed and user-friendly interface. However, I believe that to attract more users to your platform, it would be beneficial to consider supporting VS Code extensions.

Many developers rely on VS Code extensions to enhance their workflow. The ability to leverage the vast library of VS Code extensions could make Zed more appealing to a wider audience. This could help improve the adoption of Zed. Moreover, I don't think many developers would want to rewrite their extensions for a small and new app like Zed, at least not just yet.

You can implement your custom extension API for more performance too, but it can come later. VS Code extension support is a must right out of the box imo.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[shinebayar-g]

Is it even possible?

[berkus]

Is it even possible?

It is, but the amount of work here is pretty non-trivial:

• expose editor bindings for all the things that exist in vscode
  • bridge/thunk things that work differently
• support a JS runtime environment for plugins
• support compatible plugin configuration storage

[aelkoussy]

+1 with a suggestion
If you manage to add vscode extensions support with a better way of handling the really heavy extensions (like eslint for example), I think a lot of people would be excited to try and maybe switch from vscode to zed

So far, vscode is very fast and solid overall, with that problem above as a small nuisance - not sure if the host editor (vscode/zed) can control and improve the behaviour of extensions or not though tbh

[berkus]

I wonder if boa could become a JS engine to power the extensions.

[pnodet]

For reference, the Biome community and maintainers had a discussion about js engines here : biomejs/biome#2467

[kerns]

I would love to see this. I am sure it isn't trivial to implement, but the competitive adv. and stickiness of VS Code's extension ecosystem isn't trivial either.

[eimfach]

I think it would not make sense to support every vscode extension out there.. only a specific subset

[b2storefront]

can we at least short list some?

[subhasish-smiles]

This would be phenomenal !!
Was just thinking the same thing

[eimfach]

can we at least short list some?

I think you need a specification on which parts of the VSCode Extension API to support as a start ..
And a way of telling if a specific extension does meet the supported criteria. Not an easy task I might say.

[himat]

Likewise, I don't think Zed has a shot of being a daily driver for a large part of the market until extensions are supported. I had finally switched from pure vim to vscode after many years only because there were certain AI extensions that made my workflow far superior. And I think zed would need those too.

[ShalokShalom]

Likewise, I don't think Zed has a shot of being a daily driver for a large part of the market until extensions are supported. I had finally switched from pure vim to vscode after many years only because there were certain AI extensions that made my workflow far superior. And I think zed would need those too.

Zed now has AI features implemented.
See the homepage.

[thendodev]

I would like to say it doesn't matter how non-trivial the implementation is... the only real way to compete with VS Code is to support all if not most of their extensions otherwise, this is just another cool editor I can't use, there's no getting around that, it should probably be the most important focus for zed, that and the UI.

[berkus]

I would like to say it doesn't matter how non-trivial the implementation is... the only real way to compete with VS Code is to support all if not most of their extensions

The good ones shall be reasonably easy to replicate. All the other duplicate crap probably is not very necessary.

I am personally just one extension short of the "comfortable set" and rather have fast and secure extensions in wasm rather than "do what you want with entire computer" JS from VSCode.

[ShalokShalom]

I imagine it makes sense to simply document the API in a way, that assists people with porting their apps.

Idk how far wasm extensions are supported.

Ideally, its possible to simply port existing extensions from one API to another - JS can be transpiled into wasm.

[notpeter]

While this is an interesting subject to consider, but at this time we have no plans to attempt a re-implementation the VSCode Extension API inside Zed as would be required to support VSCode extensions, and as a result I'm going to convert this to a github discussion. Thanks for reporting.

[massone99]

It would be incredible to have this feature!

[naiyerasif]

Alternatively, a transpiler to easily convert a VSCode extension to Zed plugin until a developer is ready to support Zed would also be handy. This can be useful to reduce the initial migration effort for an extension developer.

[G2G2G2G]

yep this is the most possible route, especially with LLMs now

[vipexv]

I would suggest adding support for windows first.

[co-bby]

There is a Windows build but is not officially supported #15159 (reply in thread)

[vipexv]

It's mostly broken for me, i'm saying a stable build that is supported, as Windows is a big market and i think focusing on that rather than adding extension support from VSCode would be better, as i personally don't use VSCode anymore.

I use neovim btw :]

[ShalokShalom]

I guess you ruled out the Linux runtime that is build into Windows?

[G2G2G2G]

It's mostly broken for me, i'm saying a stable build that is supported, as Windows is a big market and i think focusing on that rather than adding extension support from VSCode would be better, as i personally don't use VSCode anymore.

I use neovim btw :]

No, windows users, like the general public, produce and do nothing of value for the large majority so there's no reason.

[thataboy]

zed needs a more extensive extension API first. Right now, the API is limited to LSP, themes, and slash commands.

If you build it, they will come. Or they may come. But you have to build it first.

[habruening]

Wow! 110 people like that idea.
I don't think, that it would ever be possible. Maybe it is technically feasible. But that is so much work. Have anybody ever done such a thing - reimplementing such a huge API? It is maybe not even a good API. It is just not realistic, I think. I guess the 110 people are mostly users and not programmers.
And I think, it would not even be a good idea. There are millions of extensions. But we don't need 30 extensions for bookmarks or 40 extensions for XML to be a good text editor. We must first be a good text editor. That alone attracts plugin developers. We want good and performant plugins and not just everything.

[pascalbehmenburg]

I think you are right. The past has shown that if an editor is good, people are willing to contribute. See emacs, nvim, vscode or even knowledge databases like logseq and obsidian. Might be best not to take on that burden of maintenance.

[ShalokShalom]

There are millions of extensions. But we don't need 30 extensions for bookmarks or 40 extensions for XML to be a good text editor. We must first be a good text editor.

Some might say, there are already a million good text editors.

I suggest to look into the most popular extensions, and see if we lack any API, that prevents porting, or even the existence of such a kind of extension at all.

Its probably enough to support the 100 most prominent extensions.